Check Your APNIC IPv4 Block

Put the block to work for your customers

Before bringing an APNIC IPv4 block into your network, check three things together: the registration record, the intended route and the reputation of the addresses you will use. Then test the customer service itself. You want capacity that helps you launch and grow without an avoidable detour through delivery problems.

Start with your deployment, not a “clean” label

Write down the prefix, origin ASN, deployment location and service you plan to run. A mail platform, cloud workload and subscriber access network have different needs. Those details help you choose the right checks and give your provider a clear picture of the result you want.

If you need the background, our APNIC guide explains its registration role. The record is useful for checking the resource and its contacts; practical readiness also involves routing, reputation and your own service tests.

What is a clean IPv4 block?

In operational terms, you are looking for addresses that work for your intended services, with relevant reputation findings understood and resolved. A previously used block can be suitable for a new deployment. Read its current condition and history together.

A single clean IP lookup covers that address and dataset. For an IPv4 block, consider the addresses you will deploy, any range-wide listing and the destinations that matter to your customers.

Check registration, routing and reputation

1. Confirm the prefix and operational contacts

Use APNIC Whois or its registration lookup to compare the resource, organisation and contacts with the deployment information from your provider. Resolve mismatches early so the right team can handle routing, DNS or abuse enquiries when you need them.

2. Review relevant abuse records

Look for current reports affecting your intended addresses. Compare dates and address ranges with the previous and planned use. Historical records help direct the investigation; current service behavior tells you whether a problem is still affecting delivery.

3. Understand the BGP history

Check the announced prefix and origin ASN, including relevant changes and withdrawals. Compare those observations with the provider's explanation. An origin change may reflect a planned migration, multihoming or mitigation, so establish the context before labelling it a hijack.

Prepare the RPKI ROA and IRR route information for your intended announcement. An RPKI Invalid result calls for checking the ASN and prefix length against the covering authorisation. A route without a covering ROA is a different state. Your routing team needs this distinction to choose the right action.

4. Check the lists that affect your services

Start with the Spamhaus reputation checker and the datasets relevant to your use. A multi-list tool can help locate records; the named operator's result explains what each record means. Our IPv4 blacklist guide covers the result-to-recovery steps.

5. Observe the services you bring online

During a controlled deployment, inspect your own connection and application logs. Look for unexpected outbound activity, repeated delivery errors or incorrect source addresses. Ordinary unsolicited Internet traffic alone does not tell you that the new block is unusable.

6. Know who can deliver the handover

Confirm who will arrange the address supply, intended routing authorisation, reverse DNS and operational support. Direct access to the responsible provider makes it easier to coordinate a launch or resolve a problem without a chain of intermediaries.

7. Check the address range fits the intended use

Verify the exact prefix is suitable for public deployment, rather than a private, documentation or other special-purpose range. If your project involves a transfer, settle the relevant registration steps before scheduling the handover. Keep the technical work connected to the date your customers need service.

Turn the checks into a deployment decision

What to establish before you add customer traffic

Check	Useful evidence	Customer benefit
Registration and contacts	The expected resource record and reachable operational contacts.	Your team knows who can help with the handover.
Routing	The intended ASN, suitable route authorisation and observed reachability.	Traffic can reach the network you are building.
Reputation	Relevant lookup results, reasons and completed recovery work.	Fewer surprises when customers begin using the addresses.
Service test	A successful API request, customer connection or test-message result.	The checks connect to the experience you are selling.

Test the customer path before the launch

Use a small deployment to verify DNS, application access and the routes that matter. For email, review sending authentication and the receiving service's response alongside IP reputation. For location-sensitive services, check the relevant geolocation database and its correction route.

This brings problems into view while your team can still fix them without moving a full customer base. The leased-IP readiness guide provides a practical checklist for that launch.

Keep expansion moving in Asia–Pacific

Growing networks need a repeatable way to bring capacity online. Combine address checks with a supply relationship that supports your next deployment and the one after it. That lets your team spend more time connecting customers and less time restarting the search for usable addresses.

Choose continuity beyond the first handover

A completed transaction and a clean lookup describe a moment in time. Your customers need the addresses to keep supporting their services. LARUS's first-party model puts address supply and Continuity in a direct operating relationship, helping keep registry-facing work upstream of your day-to-day network.

Keep control of your own network

Your network team should retain the ability to choose its routing, transit and service architecture. Align the address records and authorisations with those choices. The commercial goal is usable capacity and customer continuity, with your network remaining yours to operate.

Get the supply behind your next launch

Check the block for the service you intend to deliver, resolve the findings that matter, and build on direct supply. LARUS brings Unlimited IPv4 and Continuity to network operators who want room to grow while keeping their customers connected.

APNIC IPv4 readiness questions

Does an APNIC registration record mean the addresses are clean?

It helps you establish the resource and contact details. Add reputation, routing and service checks to understand how the addresses will work in your network.

Is one successful lookup enough for a whole block?

Check the addresses you plan to use and any listings that apply to a wider range. Match the coverage to your deployment instead of extending one result to every address.

Does a different origin ASN prove a routing hijack?

No. Compare the change with the operational history and intended routing arrangement. Establish whether it was an authorised change and whether the current announcement matches your plan.

Can IPv4 work alongside IPv6?

Yes. A dual-stack deployment can serve customers using either protocol. Test both paths against your applications and access networks so the transition supports the service experience you want to deliver.

How can LARUS help me expand?

Choose a LARUS IPv4 plan for your network and work directly with the provider behind the supply. Unlimited IPv4 and Continuity give your team a commercial foundation for new deployments and the customer services already running.