GetNet Inc.: The Economic Afterlife of a Phoenix ISP Address Block

GetNet Inc.: The Economic Afterlife of a Phoenix ISP Address Block

GetNet Inc. is best understood not as a currently visible operating broadband provider, hosting company, or access ISP, but as the surviving registry shadow of a once-operating Phoenix-area Internet business whose most economically legible asset was IPv4 address space. The public record shows a company lineage that was operationally real in the late-1990s and early-2000s: dial-up access, DSL-related access, web hosting, co-location, dedicated Internet connectivity, DNS, and customer email. It also shows a present-tense resource story in which the older network identity no longer appears to carry active routing power. The central economic event is that the IPv4 block historically associated with GetNet, 216.19.192.0/19, is now registered in ARIN to Magnite, Inc., an advertising technology company, not GetNet. ARIN records list that /19 as a direct allocation to Magnite, Inc. under the ADMON organization, with registration dated 17 December 2024 and an update on 15 October 2025.

That fact changes the interpretation. The directory row points to GetNet Inc.; the ARIN organization record still exists; the old address, telephone number, and point-of-contact structure still tie back to Phoenix. But the resource that made the identity economically interesting appears to have moved. GetNet’s legacy identity therefore matters less as an ongoing local ISP and more as a case study in how defunct or thin network companies can retain, monetize, transfer, or lose economically scarce number resources long after the retail-facing business has faded.

The starting ARIN organization record is unambiguous on identity but not on operations. ARIN’s public record for organization handle GTNT lists “GetNet Inc.” at 333 E Indian School in Phoenix, Arizona, with registration date 29 June 2001 and last update 22 August 2024. The related ARIN point-of-contact records show administrative, abuse, and technical functions tied to GetNet contacts. A legacy network-operations contact, GET-NOC-ARIN, gives the same Phoenix address, the telephone number +1-602-264-7000, and the email address admin@getnetinc.net, but ARIN also says it attempted to validate that point of contact and received no response since 25 June 2025. In registry economics, this is a meaningful signal. It does not prove corporate dissolution. It does suggest that the public-facing administrative surface of the network identity is thin.

The older business was not fictitious. A public operator announcement in April 2001 said former management and employees of GetNet/Internet Access Inc. had formed GetNet Inc., described the company as an ISP offering dedicated Internet connectivity, web hosting, co-location, dial-up access, and network consulting, and said GetNet Inc. had licensed rights to the getnet.com and neta.com domains. The same notice identified Jeffrey Gong as president and said network operations were expected to start immediately. That announcement reads like a successor formation after a prior Internet Access/GetNet/Neta business had already built local customers, names, and technical infrastructure. It is the opposite of a shell-company origin. The shell-like quality appears later, after the operating market moved on.

The visible resolution is therefore: GetNet Inc. was an operating ISP/hosting/access provider in its commercial period; it appears to have been a successor or continuation of an older GetNet/Internet Access/Neta.com network business; it does not appear, on the public evidence now visible, to be an active operating ISP; and the principal historical IPv4 asset is now registered and routed under a different company, Magnite. The residual GetNet identity is economically important because it illustrates the conversion of a local service business into a number-resource asset story.

The company as an economic object

The hard public record begins with names and addresses, but the economic object is a bundle: corporate name, network reputation, customer email dependencies, DNS authority, domain names, routing relationships, local-loop access arrangements, and IPv4 registrations. In the early commercial Internet, those elements were often integrated in a single local ISP. The customer bought “Internet service,” but the provider actually controlled several different bottlenecks: the dial-up number, the DSL relationship with the incumbent telephone company, the mailbox, the domain registration, the name servers, the hosted website, the static IP address, and sometimes the co-located server.

GetNet’s public footprint fits that pattern. The April 2001 announcement stated that GetNet Inc. offered access, hosting, co-location, dial-up, and consulting. It also emphasized continuity of email addresses at getnet.com and neta.com, which is commercially important because email identity was a retention device in the dial-up and early DSL period. A third-party historical WHOIS mirror for a domain registration listed GetNet, Inc. as registration service provider and said GetNet could be contacted for domain passwords, DNS/name-server changes, and general domain support. A later web-directory snapshot for get.net described “Your Internet Service Provider From GetNet.Com” as a full-service Phoenix-area Internet provider offering web hosting, dedicated servers, virtual private servers, DSL, dial-up, wireless, email, Plesk, cPanel, and Linux services, with name servers inside the 216.19.192.0/19 address range.

That mix matters. A small ISP with only retail access customers is exposed to price compression as cable, telco DSL, wireless, and national backbones scale. A small ISP with email accounts, hosted domains, name servers, and static addresses holds higher switching costs. A customer can change a dial-up or DSL line more easily than it can renumber servers, transfer DNS, rewrite MX records, migrate mailboxes, preserve old email contacts, and move hosted applications. For business customers, the ISP is embedded not just in connectivity but in identity and operations.

The early evidence also suggests that GetNet’s market position depended on incumbent telephone infrastructure. A 1999 public posting by Internet Access Inc. d/b/a Getnet solicited former customers for evidence that US West had discouraged them from using Getnet/Internet Access or any independent ISP when ordering phone, DSL, or ISDN service. It said the company had a complaint with the Arizona Corporation Commission regarding US West’s alleged anti-competitive marketing. An Arizona Corporation Commission eDocket search result separately identifies a formal complaint by Internet Access, Inc. d/b/a Getnet against U S West, filed by Jeffrey Gong. The mechanism is straightforward: the local access provider controlled the copper loop and customer ordering path, while independent ISPs attempted to sell service over that access layer. If the incumbent could influence customer choice at the moment of provisioning, the independent ISP’s acquisition funnel was fragile.

An Arizona State University listserv-style procurement/channel trace from 2001 listed GetNet, Inc. among Qwest-supported ISPs, with the Phoenix telephone number 602-264-7000 and getnet.com, and separately listed Internet Access Inc. DBA or GetNet with another Phoenix number and getnet.com or neta.com. This is not a full operating history, but it supports the market-structure picture: GetNet sat in the layer of independent ISPs that needed incumbent last-mile systems to reach DSL customers. The value proposition was local Internet service, but the strategic constraint was wholesale access.

The successor problem

GetNet’s public history is not a clean corporate line. It is a successor problem.

There is an older “Getnet International” identity in ARIN-related records. Cidr-report’s ARIN-derived listing for AS5784 identifies “GETNET - Getnet International, US,” gives ASNumber 5784, ASName GETNET, registration date 24 October 1995, update date 18 January 2001, and an organization address at 333 E. Indian School Road, Phoenix. It also ties abuse and technical contacts to Getnet Inc. and the admin@getnetinc.net email address. ARIN’s public organization record for the later GetNet Inc. handle GTNT was registered on 29 June 2001 at the same Phoenix address. The two registry objects are not identical, but the address, name family, and point-of-contact pattern make them economically connected.

The 2001 operator announcement helps explain why. It said former management and employees of GetNet/Internet Access Inc. had formed GetNet Inc. and that the new company had licensed rights to the neta.com and getnet.com names. That language suggests a deliberate continuity strategy rather than a simple new entrant. Customers knew the names; the domains carried installed-base value; the staff carried local operational knowledge; the network identity could survive a legal or operating discontinuity.

There was also customer uncertainty. In a March 2000 Usenet discussion, one poster described neta.com as formerly GetNet/Internet Access, asked about DSL service over US West, and referred to GetNet having filed for bankruptcy and being bought by Neta. That is a customer-side statement, not an official record, and should be treated as rumor rather than fact. But commercially it is still useful: customers were trying to infer continuity, reliability, and ownership from a confusing brand trail. Another customer in the same thread said they had been a customer for years, had experienced few problems, and had kept a neta.com account even while using another access provider for the physical connection. That is the retention mechanism in miniature. The access path could move; the account identity could remain.

The successor issue matters because number resources often outlive operating companies. ARIN’s records are organized around organizations, points of contact, networks, and ASNs; they are not a narrative corporate history. ARIN describes Whois/RDAP registration data as including number resources issued by ARIN or its predecessors, organizations, points of contact, and customer reassignment information from ISPs. That registry model is operationally necessary, but it creates interpretive risk. A company name in a registry does not necessarily mean a current ISP is selling service. It may mean a resource holder exists, a contact remains, an old org object was maintained, or a transfer path was preserved.

For GetNet, the successor problem has at least three layers. First, the 1995-era Getnet International and AS5784 identity appears to predate the 2001 GetNet Inc. organization handle. Second, Internet Access Inc. d/b/a Getnet/Neta.com appears in customer, regulatory, and channel traces before the 2001 formation. Third, the post-2001 GetNet Inc. identity appears to have inherited or licensed customer-facing names and possibly infrastructure. The economic continuity is stronger than the legal continuity that can be established from the open evidence.

The address block as the hard asset

The historically important address resource is 216.19.192.0/19. A /19 contains 8,192 IPv4 addresses. A historical WHOIS mirror listed the block as GETNET-BLK1, NetRange 216.19.192.0 to 216.19.223.255, CIDR 216.19.192.0/19, NetType Direct Allocation, organization GetNet Inc., registration date 29 June 2001, and name servers ns1.getnet.net and ns2.getnet.net. The same historic mirror said addresses inside the block were non-portable.

The non-portability note is commercially important. For customers who obtained addresses from an ISP’s allocation, those addresses normally belonged to the provider’s address plan rather than the customer’s independent registry rights. A business customer could run servers, mail, VPNs, DNS, or access-control lists on those addresses, but if it changed providers it might need to renumber. That made an ISP’s address block a retention asset. It also made the ISP’s collapse or sale a customer migration risk.

In the pre-exhaustion era, a small regional ISP’s IPv4 allocation was an input to service delivery. In the post-exhaustion era, it became a tradable scarce resource. ARIN announced that its IPv4 free pool reached zero on 24 September 2015 and stated that approved requests could be fulfilled through a waiting list or the IPv4 transfer market. ARIN’s current IPv4 guidance says the free pool is depleted, that waiting-list requests can be filled only when ARIN receives inventory through returns, revocations, IANA distribution, or other sources, and that organizations may seek IPv4 space through transfers to specified recipients under NRPM 8.3 or 8.4.

This changed the balance sheet of old ISPs. A local access business could lose retail relevance while its IPv4 block appreciated or remained saleable. Public broker data should not be treated as a specific valuation for GetNet’s block, but it gives scale. IPv4.Global reported in May 2026 that market demand and transaction volume remained strong, with supply tightening and large-block prices rising slowly. The same broker has described a correction in large-block pricing from early-2024 highs in the $50-per-address range toward roughly $20-per-address levels for some large blocks, while other market commentary has described recent IPv4 prices in broader ranges depending on block size, registry, reputation, and demand. At illustrative prices of $20, $30, or $40 per address, a clean /19 would imply gross address value of about $164,000, $246,000, or $328,000 before broker fees, legal costs, registry work, reputation discounts, or transition costs. Those figures are not an asserted transaction price; they show why an old ISP identity can remain economically relevant even after its customers are gone.

The transfer mechanism itself also has economic content. ARIN says that for specified transfers, the source organization must be the current registered holder, must not be involved in a resource-status dispute, must provide a signed and notarized officer acknowledgement, and must meet minimum-size and other requirements. ARIN also says a source organization involved in an 8.3 or 8.4 transfer is responsible for a clean transition, including ROAs, IRR objects, reverse DNS delegation, and coordination with the recipient. Those requirements mean an old registry identity is not just a label. It is the administrative key through which scarce addresses can be transferred, regularized, or blocked.

The routing evidence

The routing evidence points away from active GetNet operations.

Hurricane Electric’s BGP Toolkit page for AS5784 identifies it as Getnet International and says the AS has not been visible in the global routing table since 27 April 2024. It shows no currently announced IPv4 or IPv6 prefixes and no originated valid or invalid RPKI prefixes for that AS. Cidr-report similarly states that AS5784 is not currently used to announce prefixes in the global routing table and is not visible as a transit AS. That does not prove every private or internal function is gone, but for an ISP or hosting provider, absence from the global BGP table is strong contrary evidence. An access ISP, hosting network, or colocation provider normally needs visible routed prefixes, upstream transit, downstream customers, or peering.

The address block now tells a different story. Hurricane Electric’s BGP Toolkit reports that the aggregate 216.19.192.0/19 is not visible in the global routing table. But the current AS26667 page for Magnite shows IPv4 prefixes originated by AS26667 that include 216.19.192.0/20 and 216.19.208.0/20, both under ADMON customer records. ARIN’s current record for the parent /19 lists Magnite, Inc. as organization ADMON, and ARIN’s reassignment record for 216.19.208.0/20 lists customer ADMON in Ashburn, Virginia, with registration and update dates of 10 September 2025.

That routing pattern is economically coherent. The old aggregate has been re-homed into a larger platform operator’s network and announced as two /20s rather than as the historical /19 aggregate. Magnite’s AS26667 profile shows a substantially more modern routing posture: 19 announced prefixes, IPv4 and IPv6 presence, many observed BGP peers, and Internet exchange participation. Netify’s third-party application-network data also lists 216.19.192.0/19 among Magnite network ranges, alongside other Magnite ranges. The resource has not disappeared. It has changed economic layer.

This matters because BGP visibility is a market signal. When an old ASN stops announcing prefixes, the associated company may still legally exist, but it has lost the external network function that made it an ISP. When the old address space appears under a buyer’s ASN, the value has migrated from local connectivity to platform infrastructure. The asset is still productive, but no longer in the hands, brand, or operating context suggested by the old directory row.

What Magnite changes

The current holder of the historical /19 is not a local Arizona ISP. Magnite describes itself as the world’s largest independent sell-side advertising company, providing technology that lets publishers monetize content across CTV, online video, display, and audio, and lets agencies and brands execute advertising transactions. Its 2026 quarterly filing described Magnite as an independent omni-channel sell-side advertising platform that automates the purchase and sale of digital advertising inventory.

Why would an advertising technology platform want IPv4 address space? The public sources do not state Magnite’s motive for this specific block, so the explanation must be inferential. Programmatic advertising infrastructure depends on large-scale, low-latency, reputationally controlled network operations: ad serving, bid requests, measurement, fraud controls, user-sync endpoints, data exchange, logging, and geographically distributed delivery. IPv4 addresses are not merely connectivity inputs. They support traffic segregation, reputation management, geolocation, access control, reverse DNS, operational isolation, and migration flexibility. A platform that processes billions of advertising transactions each month has a different address-demand profile from a small local ISP, but it still values clean routable IPv4. Magnite says leading agencies and brands use its platform to execute billions of advertising transactions each month.

The movement of the /19 into Magnite’s registry and routing environment therefore represents a structural change in where IPv4 scarcity is monetized. In 2001, a Phoenix ISP needed IPv4 addresses to assign to dial-up pools, DSL users, hosted domains, virtual hosts, and dedicated servers. In 2025, a sell-side advertising platform may need addresses to run distributed digital infrastructure with reputational and operational separation. The same 8,192 addresses support different business models across time.

This is the broader thesis: old ISP address space is not dead inventory. It is a scarce input that can be re-priced when control passes from declining local access businesses to scaled platform operators. The old company identity is economically meaningful because it may be the administrative bridge through which the resource moves.

Residual holder or acquired business?

The public evidence does not support saying that Magnite acquired GetNet Inc. as an operating company. It supports saying that the IPv4 block historically associated with GetNet is now registered to Magnite and appears in Magnite’s routing footprint. ARIN records show the /19 as a current Magnite direct allocation, not as a GetNet allocation. Routing data shows more-specific /20s originated by Magnite’s AS26667, not by AS5784.

That distinction is critical. Number-resource transfers, merger/reorganization transfers, and corporate acquisitions are different economic events. ARIN’s transfer guidance distinguishes transfers based on mergers, acquisitions, and reorganizations from transfers of released number resources to specified recipients. Public ARIN output visible here does not say which path was used for the GetNet-to-Magnite resource change. Therefore the economically conservative conclusion is that the resource changed registry control; the business did not necessarily sell as a going concern.

The probability of a going-concern ISP acquisition appears low on public evidence. There is no visible modern GetNet service site comparable to a live ISP product catalogue. Current Phoenix broadband-provider listings emphasize large cable, telco, fixed-wireless, satellite, and fiber providers; GetNet does not appear in those modern consumer access lists. The ARIN POC validation failure in June 2025 also points to weak current operational contactability. The old domain and directory evidence points backward to service offerings, not forward to current sales.

A residual number-resource holder is not necessarily inactive in a legal sense. It may hold an ASN, domain names, trademarks, mail systems, or customer remnants. But from an infrastructure-economics perspective, a resource holder without visible BGP announcements, without current product pages, without validated POCs, and without the historical /19 in its name is not economically equivalent to an operating ISP.

Customer dependence and lock-in

The old GetNet business likely generated customer lock-in through four mechanisms.

The first was email identity. The 2001 operator announcement specifically addressed people seeking long-term use of email addresses at getnet.com and neta.com and directed them to contact GetNet. In the early commercial Internet, email address continuity was a powerful switching cost. A residential user might tolerate changing access methods; a small business with printed materials, customer contacts, and account registrations tied to an ISP mailbox had more to lose. The Usenet customer who kept a neta.com account while using another access provider illustrates that separation of access and identity.

The second was DNS and domain administration. A third-party historical WHOIS record described GetNet as a registration service provider that could handle domain login/passwords, DNS/name-server changes, and domain-support questions. For small businesses, that role is sticky. The provider may host the authoritative name servers, register the domain, administer email records, and hold credentials. Migration requires not just a new circuit but administrative recovery.

The third was hosting and server placement. GetNet publicly described itself as offering web hosting, co-location, dedicated Internet connectivity, and later directory traces refer to dedicated servers and virtual private servers. Hosting customers face data migration, DNS cutover risk, IP renumbering, and downtime exposure. Co-location customers face physical movement, cross-connect changes, and routing changes. These switching costs can preserve revenue even as consumer access commoditizes.

The fourth was non-portable addressing. The historic WHOIS mirror for GETNET-BLK1 stated that addresses in the block were non-portable. That language turns number resources into a provider-controlled customer tether. If a customer’s server, VPN, or mail system relied on an address inside GetNet’s block, switching providers meant renumbering unless the customer had its own portable space or negotiated special arrangements. For the ISP, non-portability protected churn. For the customer, it created dependency.

These mechanisms also explain why an old block can carry hidden obligations. If live customers remain on a block, transfer is not a pure asset sale. It requires renumbering, service continuation, or customer assignment/reassignment management. ARIN’s transfer guidance explicitly highlights clean transition tasks such as ROAs, IRR records, and reverse DNS delegation. The public record does not show whether any GetNet customers remained by 2024. If none remained, the /19 was a cleaner monetizable asset. If some remained, the transfer would have required migration or service absorption.

The incumbent constraint

GetNet’s local economics were shaped by the access-layer structure of Phoenix telecommunications. Independent ISPs in the late 1990s and early 2000s often depended on incumbent local exchange carriers for DSL, ISDN, and provisioning interfaces. The 1999 Getnet/Internet Access posting about US West’s alleged anti-competitive marketing shows that GetNet understood the incumbent’s customer-contact role as a strategic threat. The Arizona Corporation Commission docket trace supports the existence of a formal complaint on that issue.

This is not a side issue. It helps explain why local ISPs could be operationally competent and still structurally disadvantaged. They could run mail, DNS, hosting, dial-up modems, and local support. But when broadband replaced dial-up, the customer-acquisition path moved closer to the telephone or cable company. The incumbent could bundle access, billing, installation, modem equipment, and support. The independent ISP’s differentiated assets narrowed to service quality, technical support, email continuity, hosting, local reputation, and static addressing.

GetNet’s channel traces suggest participation in the Qwest-supported DSL ecosystem. But participation did not remove the structural constraint. In a broadband transition, scale mattered: backbone purchasing, peering, modem pools, DSL aggregation, support staffing, billing systems, abuse handling, and marketing. Local ISPs that did not consolidate or specialize often became hosting shops, domain/DNS caretakers, or residual resource holders.

The current Phoenix access market underscores the structural change. Modern provider listings for Phoenix are dominated by large cable, telco, fixed-wireless, fiber, and satellite brands, not by the early local ISP names. That does not prove GetNet has no remaining customers, but it does mean GetNet is not visible as a meaningful current access competitor in the consumer-provider discovery layer.

The namespace confusion

There is also a brand-confusion problem. A modern search for “Getnet” frequently returns Getnet by Santander, a payments platform operating in Latin America and Iberia, not the Phoenix ISP identity. The current Getnet payments site calls itself “The Leading AI Payments Company in Latin America and Iberia,” and Santander materials describe Getnet as a payments business with e-commerce and merchant-payment services. This is unrelated to the ARIN target except as an information-retrieval hazard.

That hazard has economic significance. When an old network brand stops producing current web signals, other entities with similar names can occupy the search surface. The directory row and ARIN handle become more important because ordinary web search no longer identifies the relevant infrastructure identity. For investigators, lenders, customers, or counterparties, the risk is false continuity: a live “Getnet” brand in payments should not be mistaken for the Phoenix GetNet Inc. network-resource holder.

The same problem appears inside the historical GetNet/Neta/Getnet International/Internet Access chain. Different names appear in different records. Some sources use GetNet Inc.; some use Getnet International; some use Internet Access Inc. d/b/a Getnet; some use Neta.com. The economic continuity is plausible, but the legal continuity is not fully resolved from public sources. For number-resource analysis, that ambiguity matters because the party able to sign a transfer, maintain a POC, or assert rights is the legally recognized holder, not necessarily the brand customers remember.

What the unresolved facts would change

Several facts remain unresolved, and each has different economic weight.

The first is the transfer basis for 216.19.192.0/19. If the block moved through an ordinary specified-recipient transfer, the story is an old resource holder monetizing scarce IPv4. If it moved through a merger, acquisition, or reorganization transfer, the story could involve a broader asset or corporate transaction. ARIN’s public record establishes Magnite’s current registration, but not the commercial agreement behind it. ARIN’s transfer guidance shows that different transfer categories exist and have different requirements.

The second is customer continuity at the moment of transfer. If GetNet had no active downstream customers on the block, the transfer was largely a registry, routing, and reverse-DNS exercise. If customers remained, the transfer also involved service migration, renumbering, or customer contract disposition. Public routing evidence suggests AS5784 is now inactive, but it does not reveal whether private customer migrations occurred before public visibility ended.

The third is the status of AS5784. The AS remains historically associated with Getnet International, but it is not currently visible in global routing. An ASN without routed prefixes can still be retained as an administrative object, but its economic value is much lower than a routed IPv4 block. It could regain relevance if paired with address space or used in a private/interconnection context, but no public evidence supports that today.

The fourth is control of domain names and customer identity assets. The 2001 announcement said rights to getnet.com and neta.com were licensed to GetNet Inc., and said the GetNet trademark and certain domains were owned by Jeffrey Gong. Public directory traces later show get.net and getnet.com-related infrastructure, but not a current operating product surface. If domain assets remain under common control with the old registry entity, there may still be residual mailbox, DNS, or brand value. If they were sold, expired, or repurposed, the residual value is narrower.

The fifth is reputation. IPv4 buyers care about abuse history, blocklisting, geolocation, prior PTR records, and customer residues. Hurricane Electric’s page for 216.19.192.0/19 shows historical DNS records, including old names such as ns1.inficad.com and ns2.inficad.com inside the range. Such traces can help reconstruct prior usage, but they do not by themselves prove current risk. For a buyer, the key question is whether the block can be cleaned, re-geolocated, routed, and used without inherited reputation penalties.

The economics of disappearance

The GetNet case shows a general pattern in Internet infrastructure economics: the business may disappear before the resource identity does, and the resource identity may remain valuable after the business disappears.

A local ISP’s visible disappearance can occur gradually. First, new access signups slow because cable and telco broadband scale. Second, dial-up revenue collapses. Third, hosting and email customers remain because they are sticky. Fourth, the provider stops marketing broadly but continues to maintain legacy services. Fifth, technical staff or owners preserve registry records, domains, and name servers. Sixth, the remaining IPv4 block becomes more valuable as IPv4 scarcity deepens. Seventh, the resource is transferred to a platform, hosting company, cloud operator, security firm, adtech company, or broker-mediated buyer. The old company name remains in historical WHOIS mirrors, BGP archives, customer memories, and business directories.

GetNet appears to fit much of that arc. It was an actual Phoenix ISP and hosting provider; its predecessor/successor chain carried customer identity assets; it operated in a market structurally pressured by incumbent access providers; its historical /19 became a scarce IPv4 asset; and the block now appears under Magnite rather than GetNet.

The most important analytical caution is not to overstate the current company from the old registry row. ARIN’s GTNT record is real. It identifies GetNet Inc. But the current economics of the historical network cannot be inferred from that organization record alone. The better evidence is the combination of registry control, POC validation, BGP visibility, RPKI/IRR posture, product visibility, and historical operating traces. That combination says: once operating ISP; now residual identity; principal address asset transferred or re-registered to Magnite; AS not visibly active; no strong evidence of current access or hosting operations.

This is exactly the kind of case where address-resource economics creates information gain. Without the ARIN and BGP evidence, GetNet might look like a small dormant local company. With the resource evidence, it becomes a transaction-like story about how scarce IPv4 migrates from first-generation local ISPs to scaled digital platforms.

Evidence ledger

ARIN organization record for GetNet Inc. ARIN’s public record for organization handle GTNT lists GetNet Inc., 333 E Indian School, Phoenix, Arizona, registration date 29 June 2001, and last update 22 August 2024.

ARIN related POC record for GTNT. ARIN lists administrative, abuse, and technical POCs tied to the GetNet organization record.

ARIN GET-NOC-ARIN POC. ARIN lists Getnet Inc. at the same Phoenix address, telephone +1-602-264-7000, email admin@getnetinc.net, and states that ARIN attempted POC validation but received no response since 25 June 2025.

ARIN current parent network record for 216.19.192.0/19. ARIN lists NetRange 216.19.192.0 to 216.19.223.255, CIDR 216.19.192.0/19, NetName ADMON, NetType Direct Allocation, organization Magnite, Inc., registration date 17 December 2024, and last update 15 October 2025.

ARIN current subrange/customer record. ARIN lists 216.19.208.0/20 as MAGNITE-IAD6-2, reassigned to customer ADMON in Ashburn, Virginia, with registration and update dates of 10 September 2025.

Historical WHOIS mirror for GETNET-BLK1. A third-party WHOIS mirror preserves older data listing 216.19.192.0/19 as GETNET-BLK1, Direct Allocation to GetNet Inc., with non-portable addresses and GetNet-related name servers. This is useful as historical evidence but not current authority.

Cidr-report ARIN-derived AS5784 page. Cidr-report identifies AS5784 as GETNET / Getnet International, shows the Phoenix address, and states that the AS is not currently used to announce prefixes in the global routing table or visible as a transit AS.

Hurricane Electric BGP Toolkit for AS5784. HE identifies AS5784 as Getnet International and says it has not been visible in the global routing table since 27 April 2024, with no currently announced prefixes.

Hurricane Electric BGP Toolkit for 216.19.192.0/19. HE says the aggregate /19 is not visible in the global routing table and shows historical DNS traces inside the block.

Hurricane Electric BGP Toolkit for AS26667. HE identifies AS26667 as Magnite, Inc. and shows active prefixes including 216.19.192.0/20 and 216.19.208.0/20 under ADMON records, along with a broad peering and routing footprint.

Netify network intelligence for Magnite. Netify lists 216.19.192.0/19 among Magnite network ranges, corroborating the association of the old GetNet block with Magnite’s present infrastructure footprint.

April 2001 GetNet Inc. operator announcement. A public Google Groups posting says former management and employees of GetNet/Internet Access Inc. formed GetNet Inc.; describes services including dedicated connectivity, web hosting, co-location, dial-up, and consulting; identifies licensed rights to getnet.com and neta.com; and names Jeffrey Gong as president.

October 1999 Internet Access Inc. d/b/a Getnet posting. A public posting solicits former customers regarding US West’s alleged anti-competitive conduct and refers to a complaint before the Arizona Corporation Commission.

Arizona Corporation Commission docket trace. ACC eDocket search results identify a formal complaint by Internet Access, Inc. d/b/a Getnet against U S West, filed by Jeffrey Gong.

March 2000 Usenet customer discussion. A customer discussion refers to Neta.com/GetNet/Internet Access continuity, includes an unverified bankruptcy/acquisition rumor, and separately includes a customer comment about retaining a neta.com account while using another access provider.

ASU/Qwest-supported ISP list. A 2001 channel/procurement trace lists GetNet, Inc. and Internet Access Inc. DBA/GetNet among Qwest-supported ISP options, with Phoenix contact numbers and getnet.com/neta.com references.

Historical domain/DNS service-provider trace. A third-party domain record lists GetNet, Inc. as registration service provider for domain support, DNS/name-server changes, and related account functions.

Historical web-directory trace for get.net/GetNet. A directory snapshot describes GetNet as a full-service Phoenix-area Internet provider offering hosting, dedicated servers, VPS, DSL, dial-up, wireless, email, Plesk, cPanel, and Linux services, with name servers in the old address range.

MIT traceroute handout. A 2000 traceroute from trojan.neta.com shows a Phoenix Neta/GetNet-related host reaching MIT through Alter.net, supporting the existence of an operational Phoenix network before the 2001 GetNet Inc. formation.

Deaf Magazine 1995 trace. A 1995 page references Getnet International, Inc. in Phoenix and GetNet name-server involvement, supporting the older Getnet International layer of the lineage.

ARIN Whois/RDAP explanatory source. ARIN describes public registry data as covering Internet number resources, organizations, points of contact, legacy resources, and reassignment information, which frames why a registry identity is not the same thing as a current operating company.

ARIN IPv4 depletion announcement and current IPv4 guidance. ARIN announced IPv4 free-pool depletion on 24 September 2015 and describes current options through waiting lists, special-purpose policies, IPv6 adoption, and transfers to specified recipients.

ARIN transfer guidance. ARIN’s transfer documentation sets source and recipient requirements and highlights clean-transition tasks for ROAs, IRR records, and reverse DNS.

IPv4 market-price sources. IPv4.Global and IPXO provide market commentary indicating that IPv4 addresses remain monetizable scarce resources, with prices varying by block size, registry, reputation, and demand.

Magnite corporate sources. Magnite describes itself as a large independent sell-side advertising company and platform for monetizing content and executing digital advertising transactions; its 2026 filing describes technology that automates purchase and sale of digital advertising inventory.

Modern Phoenix provider-list traces. Current consumer-provider listings for Phoenix emphasize large broadband, fiber, wireless, and satellite providers and do not show GetNet as a visible mainstream access competitor.

Getnet payments-company disambiguation. Current Getnet/Santander sources describe a payments business in Latin America and Iberia, which is a different identity from the Phoenix ARIN target and creates search-name ambiguity.

Watchpoints

The first watchpoint is the ARIN history of 216.19.192.0/19. A future ARIN record, transfer log, court filing, or broker disclosure clarifying whether the move to Magnite was an 8.3 specified transfer, an 8.2 merger/reorganization transfer, or another administrative path would change the economic interpretation. A specified transfer would support an address-asset monetization thesis. A merger/reorganization transfer would raise the probability of a broader asset relationship.

The second watchpoint is AS5784. If AS5784 begins announcing prefixes again, especially prefixes not related to Magnite, that would weaken the inactive-ISP conclusion. If it remains unrouted, its value is mainly historical and administrative.

The third watchpoint is RPKI, IRR, reverse DNS, and geofeed posture for the former GetNet block. Clean ROAs, updated IRR objects, and stable reverse DNS under Magnite would indicate full technical absorption. Legacy reverse DNS or stale route objects would indicate a slower or messier transition.

The fourth watchpoint is any evidence of remaining GetNet-hosted customers. Old mailboxes, DNS zones, web-hosting accounts, co-location remnants, or static-IP users would mean the old company had more than registry residue at the point of resource transfer. No such public evidence is currently strong enough to establish continuing operations.

The fifth watchpoint is corporate control of GetNet Inc., Getnet International, getnet.com, neta.com, get.net, and getnetinc.net. Control of those names would determine whether the residual identity still has brand, mailbox, DNS, or customer-recovery value. Loss or sale of those names would leave little beyond historic records and any remaining ASN.

The sixth watchpoint is abuse reputation and geolocation of 216.19.192.0/19. For the current holder, the commercial value of the block depends not just on registry control but on whether the addresses are clean, correctly geolocated, accepted by counterparties, and free of legacy blocklisting or stale customer associations.

The seventh watchpoint is any Magnite network expansion that uses the block in new markets. If the two /20s remain announced under AS26667 and appear in more application-intelligence datasets, the block’s economic role will be confirmed as platform infrastructure rather than local access infrastructure.

The final watchpoint is stale registry contactability. ARIN’s failed POC validation for GET-NOC-ARIN is a small but important warning signal. If the GetNet POCs are updated and validated, the residual entity may still be administratively maintained. If they remain unvalidated, the public evidence will increasingly support the view that GetNet Inc. is a historical network-resource identity whose principal monetizable IPv4 asset has already moved elsewhere.