摘要

  • 2026 年 10 月 26 日的观测：AS139620 公告 2 个 IPv4 前缀共 512 个地址与 1 个 /48，可见度 269/269 和 257/257，观测到 7 个邻居，其中 2 个在路径左侧、5 个在右侧。
  • 名录记录里，名字写着 PUBLIC COMPANY，法定类型填 private_company，总分 0.95 压在两条各 0.82 的证据上，而其中 rdap.org 那条在本次核对中打不开；记录自己的 data_gaps 还在请人核对法定实体所在国。
  • 对要拿这条记录做决定的人：它能告诉你一个 AS 号存在、从 2019 年 9 月 4 日起被路由系统看到、今天早上仍在公告；它不能告诉你这家公司的规模、所有权、管理层或法律关系，而 512 个地址是一条转接边的宽度，不是这家公司的全部网络。

10 月 26 日早上，路由器看到了什么

先摆事实，再解释。RIPEstat 的路由状态查询以 2026-10-26T00:00:00 为查询时间，观测窗口标在 2026-10-26T08:00:00（RIPEstat 路由状态）。这份记录里有两个数字值得停一下看：IPv4 的可见度是 269 个 RIS 对等体中的 269 个，IPv6 是 257 个中的 257 个。满格。

满格本身不稀奇。一个只有两个前缀的源，只要它的上游在默认路由里正常传递，就不会有观测者漏掉它。真正有信息量的是后面这组：被观测到的地址空间是 2 个 IPv4 前缀、共 512 个地址，加 1 个 IPv6 前缀，长度 /48；观测到的邻居 7 个。这三个数字放在一起，画出来的不是一家全国性运营商，而是一个挂出去的转接边缘。

具体到前缀清单（RIPEstat 公告前缀）：103.142.144.0/24、103.142.145.0/24、2001:df1:4780::/48。每一条都带一条从 2026-10-12T08:00:00 到 2026-10-26T08:00:00 的时间线。这里要读得准一点：这份响应的注释说，少于 10 个 RIS 全表对等体看到的路径不会计入。所以这条时间线说明的是“在这 14 天里，这三条前缀一直在这份清单上”，它不证明 10 月 12 日当天发生过任何变更。

从一条 /23 到两个 /24

同一份路由状态记录给出了首末两次观测：第一次是 103.142.144.0/23，时间 2019-09-04T16:00:00；最近一次是 103.142.145.0/24，时间 2026-10-26T08:00:00。

把这两个点连起来，能看到一件具体的工程事实：2019 年 9 月被看到的时候，它是一个 512 地址的聚合；今天早上被看到的时候，是两条各 256 地址的 /24 分开发布。算一下就对上了——一个 /23 正好是两条 /24 的并集，不多一个地址，不少一个地址。

为什么会拆开，观测回答不了。前缀拆细可以做前缀级流量工程，可以按上游或机房分流，也可以只是当年配置留下来没人合并。反过来，如果哪天两条 /24 又收回到一条 /23，那同样是一个值得记录的变更，而不是“什么都没发生”。看待这件事的正确姿势是：把通告形态当形态，别当动机。

七个邻居，两个方向，别急着叫客户

邻接数据（RIPEstat AS 邻居）给出 7 个观测到的邻居，分成两组。

左侧两个：AS38082，power 568，IPv4 对等体 1007，IPv6 对等体 0；AS4651，power 1109，IPv4 对等体 1230，IPv6 对等体 499。右侧五个：AS139595（power 248，318，0）、AS139692（248，562，0）、AS139719（44，162，0）、AS151482（248，319，0）、AS154481（309，275，205）。

“左侧”“右侧”是 RIPEstat 按观测到的 AS 路径位置打的标签，是拓扑，不是合同。右侧的五个是 AS139620 在观测路径中出现于其上游的那些网络——把它们叫作客户、叫作买方、叫作签约对象，都是在往一份测量里塞它没有的东西。这份数据能说的只有：这五个方向存在过流量路径，以及它们的对等体规模分别有多大。

左侧那两家的身份，在这次能读到的公开记录里并没有落地。所以本文只写号，不写公司名。这不是留白修辞，是证据纪律：一个 AS 号能确认存在，不等于能确认它归谁运营。

注册表渲染出的那几行字

APNIC 的 WHOIS 文本（APNIC WHOIS）把它渲染成这样：aut-num AS139620，as-name MTNPCL-AS-AP，descr 为 MYANMAR TELECOMMUNICATION NETWORK PUBLIC COMPANY LIMITED，country 为 MM。同一次查询（APNIC 查询响应）还返回了机构 handle：ORG-MTNP1-AP。

RIPEstat 的 AS 概览（RIPEstat AS 概览）给出同一串持有者文字，把这个号放在 139578-140601 这个号段里，号段描述是 Assigned by APNIC，归属 IANA 的 32 位自治系统号注册表，并对 2026-10-26T08:00:00 这个窗口报 announced true。

值得注意的是这条路走不通的地方。APNIC 自己的 RDAP 对象（APNIC RDAP autnum）在这次核对中没有返回可读记录。这意味着分配日期、对象状态、remarks 这些通常写在 RDAP 里的字段，本文一个都拿不到。谁要问“这个号是哪天分给它的”，这里的答案是没有答案，而不是某个猜测的年份。

两份文件，一个分数

现在看 BTW 名录上那条记录本身。它显示的 confidence_score 是 0.95。它的 evidence_basis 只有两条，每条各自的 confidence 都是 0.82：一条指向 rdap.org 的 autnum 文档，标注为 Public registry record；另一条指向 RIPEstat 的 AS 概览，标注为 public routing data。

问题不在于引用两条来源，引用两条来源是诚实的。问题在于 0.82 和 0.82 怎么变成 0.95。记录没有写聚合方法。而对读者更实际的一点是：指向 rdap.org 的那份文档（rdap.org autnum）在这次核对中没有解析出来，取回结果是 inaccessible，摘录为空。

一条记录引用的两份文件，一份读到了，另一份没读到，总分却从 0.82 上抬到 0.95。这不是造假指控，是一个可复现性的问题。0.95 这个数字读起来像“两份独立文件都被核对过”，实际发生的是“两个 0.82 的输入，其中一个这次没能打开”。一个诚实的展示方式要么写明聚合规则，要么在证据打不开的时候把分数保持在地板价。

名字与字段的碰撞

名录记录里的字符串是这样的：legal_name 为 MYANMAR TELECOMMUNICATION NETWORK PUBLIC COMPANY L；别名 TELECOMMUNICATION NETWORK PUBLIC COMPANY L；legal_type 为 private_company；hq_country 与 registration_jurisdiction 都填 Myanmar (Burma)，hq_country_code 为 MM。

名字里写着 PUBLIC COMPANY，字段里写着 private_company。这是两个字符串之间的不一致。就这么说，不多说一步。本文没有拿到任何成立文件、公司登记摘录或法律形式备案，所以无法判断哪一个字符串与事实不符——甚至无法排除两种说法在某个司法定义下都能成立。把这种不一致直接写成“它在冒充上市公司”，是本文拒绝做的事。

同一张卡上还有第二条缝。它一边填好了司法辖区 Myanmar (Burma)，一边在 data_gaps 里写着要核对“这家实体的法定实体所在国”，后面还跟着现时服务、可见资产、母子公司关系、对外负责的公共联系人。填了一个值，同时承认这个值没被核对过——这不是罪证，这是建卡过程的顺序问题被留在了成品里。

第三条缝更细。卡里的法名以单独一个字母 L 结尾，APNIC 的 descr 写的是 LIMITED。两种写法指向同一个持有者，这几乎没有疑问；但哪一种与成立证书一致，本文不知道。名字的尾缀在国际公司名里经常被截短，也经常被写全，两者都不构成问题，只有当你需要把它写进一份合同的主体栏时，它才成为问题。

一个 AS，被标成 virtual

记录里 resources 只有一条：AS139620，resource_type 为 asn，resource_class 为 virtual，status 为 observed，service 为 ip_transit，country 为 Myanmar (Burma)。

这里有一个我不打算绕过去的词：virtual。一个 AS 号在 URL 上、在查询里、在路由表里都是实打实的东西，但这条记录把它的资源类别标成虚拟。virtual 在这个名录体系里究竟指什么，这次核对没有拿到定义。它能被读成“这个资源不是自有地址块”，也能被读成别的分类含义。在没有定义的情况下，本文只报告字段值，不替它解释。

服务面只有一条：roles 为 provider，地区 MM，服务列表是 ip_transit 和 managed_network。两者之中，只有 ip_transit 与本文能读到的路由证据对得上——前缀在公告，邻居在传递，这是转接。managed_network 在这条记录里存在，但在这次能读到的公开材料里没有对应的可核证据。它作为一个记录字段成立，作为一个可以引用的服务能力，还不成立。

空白比文字更响

这条记录里空着的东西，排出来比填着的还长：relationships 为空数组，leadership_contacts 为空数组，related_events 为空数组，contextual_references 为空数组；first_seen_at 为 null，external_id 为 null，source_system 为 null，website 为 null，primaryDomain 为 null。status 是 queued_for_profile_article，last_updated_at 是 2026-06-17T00:04:15.536Z。

这些空白不是丑闻，是建卡顺序：先有一个 AS 号被观测到，再补人、补关系、补网站。名录页面在这里：BTW 名录条目 仅限战略圈层会员。但对一个要拿它做决定的人来说，空白决定了他能问出什么问题。没有 leadership_contacts，你没法问“出了故障谁接电话”；没有 relationships，你没法问“它和谁是一家人”；first_seen_at 为 null，你甚至不能说“这个实体是在某年某月进入名录的”，只能说这个号在 2019 年 9 月 4 日就已经在路由系统里被看到。

一个要决定的人，究竟需要什么

把读者具体化。三种人会在一条这样的记录前面停下来：想接这条转接的运营者；在评估供应商、需要填一份供应商清单的采购；要写国别或区域报告的分析者。

他们真正需要的四件事其实很朴素：这家公司还在不在运营；那 512 个地址是不是它自己的；上游是谁；出事的时候谁负责。

这次核对能给的是：AS 号真实存在；2019-09-04T16:00:00 起就被路由系统看到；2026-10-26T08:00:00 这个窗口里仍在公告；可见度几乎满格；地址空间是 512 个 IPv4 地址加一个 /48；有 7 个观测邻居，2 个在路径左侧、5 个在右侧。

这次核对不能给的是：成立文件、所有权结构、管理层名单、客户名单、总网络规模。最后一条要说明白——512 个地址是这一条转接边的宽度。一家运营商可以把整张骨干网放在别的地方，只把这一小段挂在这里；反过来，也可能这就是它全部的家当。仅凭这条记录，两种都排除不了。

所以正确的用法是把这条记录当线索，不是当凭证。线索告诉你下一步去查哪里：去要 APNIC 的分配凭证，去要一份能核对的登记文件，去问一份带 SLA 的联系人清单。凭证是别人签字的纸，不是别人打的分。

什么会推翻这篇判断

一篇讲证据边界的文章，自己也该给出证伪条件。

第一，如果 APNIC 的 RDAP 对象恢复可读，给出分配日期和对象状态，那么“本文拿不到分配日期”这一条立刻失效，关于年代的讨论要重写。

第二，如果名录把 legal_type 改成 public_company，或者有人拿出一份成立文件，名字与字段之间的张力就被解释掉了——不管是哪一个方向被解释掉。

第三，如果出现新的前缀，或者两条 /24 重新聚合成一条 /23，512 这个数字就从“当前”退回成“当时的快照”。

第四，如果 rdap.org 的那份文档恢复可读，0.95 与 0.82 之间的算术问题依然存在，但“它打不开”这一条不再成立。

第五，如果邻居集合发生变化，本文关于左右两侧的描述就得重测；测量有日期，描述也就有保质期。