Dear Zhong, Following up on this thread, I'd like to clarify three specific points based on routing data and operational reality. ## 1. MoeDove's reply: Unprofessional tone, but technically accurate While the MoeDove engineer's opening ("To idiot haoziwan.xyz") was undeniably unprofessional, their technical and legal substance was entirely correct. They raised a fundamental question: How can a prefix with zero public visibility hijack traffic? We now have RIPE RIS data confirming that AS202734 originated exactly zero hijacked Chinese carrier prefixes during the alleged window. If these routes were only visible to the HE BGP Toolkit collector via a local feed and leaked nowhere else, there was zero impact on global traffic. The reporter has yet to counter this with any actual routing data. On the policy side, MoeDove's citation of Section 6.3 of the RIPE End User Assignment Agreement is spot-on. The sponsoring LIR is not the BGP operator for the end-user's ASN; liability for resource usage rests squarely with the end-user. ## 2. Sunoaki Network saw nothing — and RIPE RIS confirms it Sunoaki Network (AS47778) peers directly with AS202734 over IPv6, and we received zero hijacked prefixes from this session. The only IPv6 prefixes we observed were their four legitimate allocations and 2a0f:1cc5:ffff::/48 (a well-known multi-origin research prefix). A query of RIPE RIS across the claimed hijack window yields the same clean slate: * May 16 — Originated v4: 0 | Originated v6: 6 (all legitimate) * May 17 — Originated v4: 0 | Originated v6: 6 (all legitimate) * May 22 — Originated v4: 0 | Originated v6: 5 (one research prefix withdrawn) The single prefix removed between May 17 and May 22 was 2a0f:1cc5:ffff::/48. This is an experimental multi-origin prefix announced across 20+ ASNs globally, marked as "Global Multi-origin Experimental Network" in WHOIS, and geolocated in Antarctica (AQ). It has absolutely nothing to do with Chinese carrier space. If 3,948 hijacked IPv4 prefixes were supposedly announced but never hit RIPE RIS collectors, they simply did not exist on the global routing table. Internal collector data from a single provider does not equal the real-world internet. If anyone has RouteViews/RIS snapshots or traceroutes proving global propagation, please share them. Otherwise, this claim holds no water. ## 3. The sponsorship is fully compliant (The "Virtual Org" myth) The ongoing claim that JIANYUELAB LTD is a "virtual organization" incapable of holding EU network infrastructure is demonstrably false. AS215172 (JIANYUELAB LTD) operates a legitimate carrier-type network with: * Direct fabric connections at LOCIX Frankfurt. * Active transit upstreams including Cogent (AS174), HE (AS6939), and xTom (AS3204). This is a real network with a physical footprint in the EU. The insinuation that a UK-registered entity cannot have European network elements ignores both geography and RIPE's service region guidelines. The RIPE NCC analyst already confirmed that the sponsor provided valid evidence of a network element within the service area. That should have settled the matter. ## Summary The narrative of a "premeditated hijack of Chinese carriers" completely falls apart under scrutiny: * Zero hijacked Chinese carrier prefixes in RIPE RIS. * Zero hijacked routes in public BIRD configurations. * Zero hijacked prefixes received by direct peers (like Sunoaki). * A fully compliant, verified sponsorship arrangement. Instead of chasing ghosts, the community's time would be much better spent on: 1. Providing actual, inline traceroute data to back up claims. 2. Accelerating ROV (Route Origin Validation) deployment, which would make arguments like this entirely irrelevant. Regards, Bo Xu Network Engineer Sunoaki Network LLC

Hello, Thanks for sharing this incident with the community. On May 17, because of an incorrect filter configuration, routers of AS202734 exported a number of prefixes from its internal routing table to the route collector of the Hurricane Electric BGP looking glass (bgp.he.net). For BGP sessions with upstream transit providers (real routers), AS202734 uses a tighter set of filters, and export only prefixes that are within a small number of whitelisted "ANNOUNCED_v4/v6" subnets. Thus, none of the said prefixes were ever exported to real routers on the internet, and this incident did not affect any public routing infrastructure. However, this incident might have triggered a number of automated emails from the HE.net looking glass to those who subscribed to updates about the affected prefixes. These are truly what one would describe as "false alarms". If you did receive one of these emails and was alerted, you have my apologies. For the benefit of the NANOG community, here is a detailed description of what triggered this "false alarm" incident. AS202734/AS402333 runs a custom fork of BIRD3 as the routing control plane for its routers. The configuration files for these routers are rendered automatically from a Jinja template- and the aforementioned export filter is no exception. The same filter template controls both routes exported to transit providers and public looking glass route collectors such as bgp.he.net. When AS202734 receives a prefix from its upstreams or IX peers, the import filter would automatically tag the route with a large community of the form ({{ cold_potato_asn }}, {{ router_ld2_id }}, {{ neighbor_asn }})). This community identifies the source of the route, as well as the AS202734 router where the prefix was learned. BGP looking glasses- bgp.he.net, bgptools, etc.- typically require a full table to be exported- not just routes whitelisted for announcement to upstreams. Since the whitelist filter no longer applies, some alternative method would be necessary to filter out routes that are in the iBGP table, but are not learned from peers or upstreams- these include internal routing infrastructure prefixes, as well as other types of routing optimizations that should not be exported to the public internet. It seems like a natural option to build this filter around the aforementioned BGP Large Community, which is supposedly applied only to routes learned from other networks, and not from the internal infrastructure. As seen in line 30 of the Jinja template below, "session_export_non_local" evaluates to True for route collectors (but not for upstream transit providers,) and routes would be accepted for export to the collectors even if they are not in the "announced" whitelist- as long as they are tagged with this large community when learned from peers or upstream. In the filter for regular upstream transit providers, the original whitelist still applies. This setup worked just as expected for months, and routes observed at AS202734 were visible through various public looking glasses, helping other networks understand the reachability of their prefixes. However, up to this point, there is no clear way to determine from which session or geographic region was a particular prefix exported- either to the route collector or to a real upstream. To resolve this, it seems natural to reuse the same large community- tagging exported routes with geographical router info and session info in the export filter. See line 15 of the code snippet below: # v6 version of the filter is shown; the filter for v4 follows the same logic 1 filter ebgp_export_v6_{{ session_id }} { 2 {% for community in session_communities %} 3 {% set community_value = community if community is string else (community | join(', ')) %} 4 bgp_community.add(({{ community_value }})); 5 {% endfor %} 6 {% for community in session_large_communities %} 7 {% set community_value = community if community is string else (community | join(', ')) %} 8 bgp_large_community.add(({{ community_value }})); 9 {% endfor %} 10 {% for community in session_ext_communities %} 11 {% set community_value = community if community is string else (community | join(', ')) %} 12 bgp_ext_community.add(({{ community_value }})); 13 {% endfor %} 14 15 # Added on the day of the incident: # bgp_large_community.add(({{ cold_potato_asn }}, {{ router_ld2_id }}, {{ neighbor_asn }})); 16 17 {% for prepend in session_prepend %} 18 bgp_path.prepend({{ prepend }}); 19 {% endfor %} 20 21 if net = ::/0 then { 22 {% if session_export_default %} 23 accept; 24 {% else %} 25 reject; 26 {% endif %} 27 } 28 29 if (net ~ ANNOUNCED_v6) then accept; 30 {% if session_export_non_local %} 31 if (bgp_large_community ~ [ ({{ cold_potato_asn }}, *, *) ]) then accept; 32 {% endif %} 33 reject; As you might have anticipated, the issue is that this newly-added BGP large community applies to all prefixes routes in the table, and not just those directly learned from upstream/peers. As a result, a large number of internal-only prefixes (4,622 to be exact) with missing BGP PATH info also received this large community. While the whitelisting mechanism prevented these prefixes from being announced to upstream transit providers, these prefixes were announced to route collectors of BGP.he.net from two of the AS202734 routers. The fix, as you might expect, is to move the filter "accept" logic into its own function, and apply any information communities only after if the "accept" function returned true and no "reject" filter was triggered. After deploying this fix and testing extensively, AS202734 is now once again contributing data to the public looking glasses- with the BGP large community included to help engineers of other networks better understand the reachability of their prefixes across geographies. To avoid similar incidents in the future, a staging environment paired with extensive code reviews might be helpful. I hereby thank the NANOG community and in particular Zhong Miao, the Independent Security Researcher, for bringing this issue to my attention so swiftly. I also appreciate comments from the community regarding best practices to make the deployment process more reliable and secure. Regards, Jacob-Junqi Tian May. 23, 2026.

Apologies to all subscribers for replying in Chinese here. Several members have already reply him in English, but the message does not appear to be getting through. I will now reply in Chinese to ensure there is no further miscommunication or evasion and to stop further time-wasting. Chinese version： 亲爱的 Zhong miao， 在看过近几天您的行为之后，包括其他人给您清楚的解释，您仍不罢休，我实在不忍心您继续在 NANOG Mail Lsit 制造这些垃圾、完全无用的信息。 首先，您发送的几乎每一封邮件的 AI 生成率几乎都是100%，我不知道您是否真的理解计算机网络，包括 BGP 等的知识（但是理论上来说，您的知识储备可能完全为0），以下是你提出的所有问题的解答。 1.关于你提到的 “AS202734 劫持中国电信网段” 在互联网路由器上，通常为了调整本网到各大 ISP 的流量，通常的做法是将这些路由“导入到路由器配置中”或是”通过过滤器分离这部分路由“，并通过配置调整本网到这些路由的流量，这是完全合规且常见的技术手段，他写入 Bird 配置的正是这些东西。 AS202734 本质上是为了区分通往中国大陆地区的流量，所以将这些路由导入到路由器配置中，这部分路由通常没有 AS-PATH，同时也不应该被导入到公网中，他犯了一个错误，也就是在向 Hurricane Electric BGP Toolkit 贡献数据时，没有将该部分路由过滤掉，与此同时 AS-PATH 为空，HE 的收集器便将该路由的起源定义为 AS202734。这只是一个向 BGP 收集器的错误导出，AS202734 并没有将这些路由发布到任何上游。在公网上没有任何可见性，不会造成任何影响。 其次，BGP 是有安全措施的，绝大多数的 ISP 都部署了 IRR/RPKI 过滤器，这些起源错误的路由就算是导出到了上游，也会被上游直接拒绝，不会发生任何事情。 Hurricane Electric BGP Toolkit 如其名称，他是一个工具，本质上是为了方便查询/研究 BGP 路由/运营商等的信息的，他的数据正是来源于数据提供者，这里只不过是数据提供者不慎提供了错误的数据，Hurricane Electric BGP Toolkit 也同时在页面上将路由标红，且显示在其他收集器的0可见性，说明这只是一条错误信息。 2.关于你提到的国家/地区信息标注错误，为什么向一个组织分配的互联网资源一定要标注本区域，抑或是在本区域使用。 绝大多数云厂商 ISP，都在从事跨国业务，他们本就可以在whois标注地理位置信息，说明他们实际在哪个地区使用该资源。（在RIR允许的情况下，这些行为毫无问题，RIPE对于您所举报的这些子网明显是允许这些行为的）。 所以，您完全没有必要在这里大费周章的朝着与他相关的邮箱发送骚扰邮件，我不知道您的目的是什么。为了互联网安全，您可以去正常研究，就算他提供错误数据，也应该是直接向他本人发邮件提醒。而不是在各处发送 Abuse，包括在这里，甚至使用 AI 生成文本，您几乎没有任何这方面的这方面储备，就在盲目使用 AI 生成邮件，发送 Abuse，您这无疑是再给社区灌屎。 您的行为不异于路边的一条疯狗在咬过路的人，完全一个傻逼。