Multacom IP Ranges
Multacom Corporation is a dedicated-server, colocation and IP transit host. ARIN assigned AS35916 to the company on 8 April 2005 at its Canyon Country, California address, and its own direct allocations start with 204.13.152.0/22 twelve days later, run through 2607:f130::/32 for IPv6 in 2007, and were extended by 142.171.0.0/16 in August 2023 and the 74.48.0.0 and 66.103.192.0/19 blocks that September. Almost none of that appears among the largest prefixes it actually announces.
- Provider
- Multacom
- Primary ASN
- AS35916
- Category
- Hosting
- Headquarters
- Los Angeles, CA, USA
- Announced IPv4 prefixes
- 183
- Registry
- ARIN
Known IP ranges
These prefixes are currently announced to the global routing table by AS35916 (MULTA-ASN1 - MULTACOM CORPORATION). Prefix sets change over time - use WHOIS Lookup for the authoritative record on any specific address.
154.92.0.0/14
156.237.0.0/16
156.242.0.0/16
154.214.0.0/16
154.81.0.0/16
154.215.0.0/16
154.198.0.0/16
154.88.0.0/16
154.218.0.0/16
156.229.0.0/16
2a0d:d480::/29
2a0d:6900::/29
2607:f130::/32 (IPv6)
What does a Multacom IP mean in a privacy test?
Everything announced by AS35916 is hosting: a machine in a rack, so a browser arriving from one of these addresses is on a rented server, a proxy or a VPN exit rather than a household line. The harder question is who the address belongs to, because the largest ranges Multacom announces are not registered to Multacom. The IPv4 sits inside two AFRINIC allocations, 154.80.0.0/12 and 156.224.0.0/11, held by Cloud Innovation Ltd of the Seychelles, a name that appears nowhere in Multacom's own ARIN records. The IPv6 goes further: 2a0d:d480::/29 is a RIPE allocation whose inet6num reads RU-NEMEROV-20180306 with country RU, and the only thing tying it to Multacom is a route6 object of Multacom's own that describes it as a customer route with an LOA provided. Treat all of that as leased space: the abuse path runs through Multacom, the ownership record names someone else, and neither of them is the end customer.
What Multacom publishes, and where the registry points instead
Multacom publishes no geofeed and no allowlist, and its own site documents products rather than address space. What ARIN records is a referral: its registration points queries at a referral whois server, rwhois://rwhois.multacom.com:4321, which is the mechanism a provider of this size uses instead of filing every downstream reassignment individually, and it is the only operator-run lookup on offer here. Its PeeringDB record nominates the IRR set AS-35916-TRANSIT, classes the network as an NSP with global scope and an open peering policy, and leaves the policy URL and looking-glass fields empty. The company's own IRR objects live in RADB under MAINT-AS35916 and occasionally carry a site: the route for 2607:f130::/32 is described as Multacom's IPv6 Network, while a more specific inside it, 2607:f130:e000::/39, is tagged EC104 - Reston, VA.
For the 154 and 156 ranges the ARIN answer is simply empty, because those are not ARIN resources. The authoritative record is AFRINIC's: two large ALLOCATED PA blocks, netnames Cloud-Innovation-v4-I and CloudInnovation-infrastructure, both held by Cloud Innovation Ltd with country SC, maintained by AFRINIC-HM-MNT and delegated downward through CIL1-MNT and LARUS-SERVICE-MNT. Below that the two behave differently, which is the part worth checking. Under 156.224.0.0/11 the route objects are uniform: page after page reading Cloud Innovation Ltd under origin AS17561, filed through MAINT-LARUS. Under 154.92.0.0/14 they are not, and the descrs name a crowd of unrelated parties: XCLOUD TECHNOLOGY LIMITED on AS149641, Antbox Network on AS138995, Yisu_Cloud_Ltd on AS142403, SALO SOLUTIONS KFT on AS209242, an OWS Hong Kong entry on AS984, CMI IP Transit on AS132839, and several that say only Proxy-registered route object. None of it identifies the party actually using a given /24.
Whose machine is on a Multacom address
Nothing on this network resembles consumer access: no subscriber pools, no carrier-grade NAT, and inbound connections are the point rather than the anomaly, so an unsolicited connection from AS35916 is unremarkable and a session that presents itself as a home user is the thing worth a second look. The split to make is between the space Multacom holds and the space it borrows. 204.13.152.0/22 from 2005, 2607:f130::/32 from 2007, 142.171.0.0/16 from August 2023 and the 74.48.0.0 and 66.103.192.0/19 blocks from that September are direct ARIN records in the name of MULTACOM CORPORATION under the org handle MULTA. An address in those is Multacom's own footprint with one company behind it.
Everywhere else, assume a reseller until proved otherwise, because Multacom's own objects say as much in their descrs. On 154.92.0.0/14 its entries read CMI (Customer Route) and Customer route - LOA provided, and the route6 for 2a0d:d480::/29 reads Customer Route - LOA Provided against an inet6num registered to a Russian holder under ORG-NEVP1-RIPE. An LOA named in a descr is the operator stating, in the registry, that it announces somebody else's addresses with permission, which is the opposite of the address being its own. Reverse DNS on that space is sparse, so the checks that work are the covering object in whichever registry actually holds it, which ASN originates the specific /24 right now rather than the /14 around it, and the abuse address ARIN holds: abuse@multacom.com reaches an operator for anything AS35916 announces, whoever the underlying registrant turns out to be.
Related tools
Frequently asked questions
What IP ranges does Multacom use?
ARIN assigned AS35916 in April 2005. Multacom's own direct allocations are 204.13.152.0/22, 66.103.192.0/19, the 74.48.0.0 blocks and 142.171.0.0/16, plus 2607:f130::/32 for IPv6. The much larger 154 and 156 ranges it announces are AFRINIC space allocated to Cloud Innovation Ltd rather than to Multacom.
Why does a Multacom IP whois to the Seychelles?
Because the registry record follows the allocation and not the announcement. The 154.80.0.0/12 and 156.224.0.0/11 allocations are held at AFRINIC by Cloud Innovation Ltd, a Seychelles company, and Multacom announces parts of them under AS35916. Both statements are true at once: AFRINIC names the holder, BGP names the operator.
Is an AS35916 address a VPN or a proxy?
It can easily be. This is dedicated-server and colocation space with no subscriber pools at all, and Multacom's own route objects on the leased ranges describe them as customer routes announced with an LOA. The same AFRINIC space carries objects from a string of unrelated small networks, so a session from AS35916 that presents itself as a residential connection deserves a second look.
Where does Multacom publish its address data?
Not in a geofeed and not in an allowlist. ARIN's record for its space refers queries to a referral whois server at rwhois.multacom.com on port 4321, which is where reassignments to downstream customers are meant to be visible, and PeeringDB nominates AS-35916-TRANSIT as its IRR set.
Why does my privacy test show a Multacom IP?
Everything announced by AS35916 is hosting: a machine in a rack, so a browser arriving from one of these addresses is on a rented server, a proxy or a VPN exit rather than a household line. The harder question is who the address belongs to, because the largest ranges Multacom announces are not registered to Multacom. The IPv4 sits inside two AFRINIC allocations, 154.80.0.0/12 and 156.224.0.0/11, held by Cloud Innovation Ltd of the Seychelles, a name that appears nowhere in Multacom's own ARIN records. The IPv6 goes further: 2a0d:d480::/29 is a RIPE allocation whose inet6num reads RU-NEMEROV-20180306 with country RU, and the only thing tying it to Multacom is a route6 object of Multacom's own that describes it as a customer route with an LOA provided. Treat all of that as leased space: the abuse path runs through Multacom, the ownership record names someone else, and neither of them is the end customer.