A School Stayed Inside Fatbeam’s ARIN Block. The Transfer Came Two Years Later.

Summary

• ARIN’s 21 August 2018 transfer file records the complete 52.144.56.0/23, 512 IPv4 addresses, moving from Ednetics, Inc. to Fatbeam, LLC. Current parent RDAP names Fatbeam; the first 16 addresses return a Bishop Blanchet High School assignment registered in 2016.
• A second Fatbeam parent, 162.142.100.0/22, arrived from Memorial Hospital of South Bend on 12 March 2020. Its first eight addresses return a Roche Fruit Ltd assignment registered on 31 August 2020. The two child dates fall on opposite sides of their parent transfers.

Type 52.144.56.0 into ARIN’s RDAP and the first name on the resulting record is Bishop Blanchet High School. Ask for the enclosing /23 and the registrant is Fatbeam, LLC. The smaller record says ASSIGNMENT; the larger says DIRECT ALLOCATION. One address, two administrative layers. A search that stops at the first answer misses the parent.

The clock makes this more interesting. The school assignment covers 52.144.56.0–52.144.56.15, just 16 addresses, and its registration event is dated 6 July 2016. Its parent handle is NET-52-144-56-0-1, the handle on today’s Fatbeam /23. ARIN’s 2 November 2026 cumulative transfer snapshot dates the complete /23 moving from Ednetics, Inc. to Fatbeam to 21 August 2018, more than two years after the child record began. ARIN labels that event MERGER_ACQUISITION. The label classifies the resource transfer row.

The parent itself supplies a third date. Its RDAP registration event reads 8 June 2016, and its last-changed event falls in 2025. The transfer file’s 2018 event time answers the handover question. Three fields answer three questions: when the parent object was first registered, when this child assignment appeared, and when ARIN recorded a change in the parent resource’s recipient. Treating the first year displayed by RDAP as the year Fatbeam received the block would make a 2018 handover seem to have happened in 2016.

A second address tests the opposite chronology. ARIN’s transfer file shows Memorial Hospital of South Bend sending 162.142.100.0–162.142.103.255, a 1,024-address /22, to Fatbeam on 12 March 2020. The original_set runs to 162.142.111.255; the transfer_set ends at 103.255. The wider source interval held 3,072 addresses, and ARIN’s row moves only the first third. Current RDAP for the /22 parent names Fatbeam and marks it DIRECT ALLOCATION.

Now query 162.142.100.0 alone. ARIN returns a narrower ASSIGNMENT, 162.142.100.0–162.142.100.7, naming Roche Fruit Ltd. Its registration and last-changed events are dated 31 August 2020, months after the March parent transfer. The child’s parentHandle leads straight back to the Fatbeam /22. The school record survived a later parent transfer; the fruit-company record appeared after a transfer. The same RDAP hierarchy can carry both timelines.

ARIN’s resource-record guide explains why the distinction matters. A direct registrant can publish a narrower reassignment for a customer, and an address query can surface that narrower object. The public transfer log records resource moves between registered organizations. RDAP tracks narrower customer assignments under the direct registrant. Following the RDAP up link and the dated transfer row restores the missing context.

ARIN’s transfer-log format guide gives original_set and transfer_set separate fields. Fatbeam has 31 incoming rows in this ARIN snapshot between 2018 and 2026: 27 IPv4, two IPv6 and two ASN rows from 18 source-name strings. That larger trail makes a one-name answer especially fragile. A reader checking any one address may encounter a child record, a parent record, or a transfer event, depending on the question. The decisive question is which layer supplied that name.