RIPE's two AS209601 receipts leave a missing handoff

RIPE Has Two Receipts for AS209601. The Names Between Them Are Missing.

Why it matters

One AS number, two transfer receipts, four different parties. RIPE NCC says `AS209601` went from MULTIVISION TRIGUEROS SL to AVATEL TELECOM, SA in 2022. Its next published transfer, on 3 November 2026, takes the same number from Yu ZuYuan to XiaoYuan Networks Limited. The public transfer list does not show how the 2022 recipient became the 2026 sender. Six IPv6 routes carrying the ASN remained in RIPEstat's observations across the later transfer date. The paperwork has a gap; the network has a pulse.

Theo March4 November 2026Reading Time 3 minLast update: 4 November 2026

Two public AS209601 transfer rows name parties that do not join; six IPv6 routes remain visible across the later date.

Summary

The RIPE NCC ASN transfer original has two POLICY entries for AS209601: 18 May 2022, MULTIVISION TRIGUEROS SL to AVATEL TELECOM, SA; and 3 November 2026, Yu ZuYuan (CN) to XiaoYuan Networks Limited (GB). The list offers no intervening transfer row connecting those parties. RIPE's transfer-statistics explanation describes the date as when a transfer was processed and the country as the organisation's legal registration at that time.
The current RIPE RDAP record names the ASN XiaoYuanNET, with registration at 6 January 2026 10:23:35 UTC and last change at 3 November 10:15:47 UTC. RIPEstat's 2–3 November and 3–4 November one-peer-threshold windows each return the same six IPv6 /48s with full-window timelines.

Four names on two receipts

Read the table as a chain of custody and it breaks at the middle. The first receipt ends with AVATEL. The second starts with Yu ZuYuan. Neither row names the other, and the published transfer list supplies no joining transaction for this ASN. An operator could have returned, surrendered, or received the number through some other documented procedure; the published rows here do not choose among those histories. A dated lifecycle record or intermediate custody document would settle the missing step. Until one appears, the precise statement is that two public transfer events exist and their named parties do not form a continuous chain.

The 2026 row moves from a CN-coded party to a GB-coded one. Those are legal-registration country codes in the transfer table, not a map of packet paths. The row records a processed policy transfer, not a sale price, change of routing equipment, or proof that traffic crossed a border. The RDAP card now names XiaoYuanNET and shows a last change on the transfer date. Its January registration date is another registry clock; it does not fill the 2022-to-2026 custody gap.

RIPEstat gives the other clock. In both consecutive daily windows, it lists 2a14:7583:e05d::/48, 2a14:7583:e0c1::/48, 2a14:7583:e0ae::/48, 2a13:9500:167::/48, 2a14:7583:e0e0::/48, and 2a14:7583:e0d9::/48 under AS209601. Each result spans its whole requested day at a minimum one-peer threshold. This is continuity in those observations, not a claim about every BGP collector or every minute of universal reachability. The ASN receipt also transfers no IPv6 prefix in its own row. Route origin is not address ownership.

The tempting headline is a cross-border network move. The more useful one is a registry evidence problem: a public list says who sent and received this ASN on two dates, while the gap between the named parties remains invisible in that list. Six routes keep the number operationally interesting. They cannot repair a broken documentary chain.