IP Address and ASN Continuity Planning: Enterprise Guide

IP Address and ASN Continuity Planning: A Practical Guide for Enterprises

IP address and ASN continuity planning is the process of ensuring that an organisation can continue using, managing and recovering its critical Internet number resources when providers change, staff leave, accounts become inaccessible, networks migrate or infrastructure fails.

For many enterprises, business continuity planning focuses on applications, databases, cloud systems, backups and physical infrastructure.

Internet number resources are often treated as technical details.

That can be a mistake.

Public IPv4 and IPv6 addresses and Autonomous System Numbers can become deeply embedded in an organisation's operations.

They may be referenced by:

• customer allowlists;
• partner firewalls;
• APIs;
• VPN gateways;
• payment systems;
• DNS;
• email security;
• cloud platforms;
• monitoring systems;
• security policies;
• BGP routing;
• RPKI records;
• and third-party reputation systems.

If those resources become unavailable, incorrectly registered or difficult to manage, the disruption can extend far beyond the networking team.

A mature continuity plan should therefore answer a simple question:

If the people, providers or administrative systems surrounding our Internet number resources change tomorrow, can the network continue operating?

What Are Internet Number Resources?

Internet number resources are globally coordinated identifiers used to support Internet routing and connectivity.

The main resources are:

• IPv4 addresses;
• IPv6 addresses; and
• Autonomous System Numbers.

The Internet Numbers Registry System provides the global coordination framework for these resources. RFC 7020 describes the system used to distribute globally unique IP address space and AS numbers.

At the global level, IANA coordinates Internet number resources.

Regional Internet Registries maintain regional registration and administration systems.

Individual network operators then use those resources inside real infrastructure.

This creates several related but separate layers:

Registry layer
Who is associated with the resource?

Routing layer
How is the prefix being announced?

Security layer
Which ASN is authorised to originate it?

Operational layer
How is the resource actually used inside the network?

Continuity planning needs visibility across all four.

Why Do IP Addresses and ASNs Need Continuity Planning?

An organisation may use the same public address space for years.

During that time, those addresses can become embedded in technical and business relationships.

For example, an enterprise may use one IPv4 prefix for:

• customer APIs;
• secure partner connections;
• external databases;
• payment gateways;
• corporate VPN access;
• public applications;
• outbound NAT;
• email infrastructure;
• and administrative services.

External organisations may then add those addresses to allowlists.

Security teams may write rules around them.

Customers may build integrations around them.

Changing the addresses may be technically possible, but the dependency is no longer limited to a router configuration.

The address has become part of the organisation's operational identity.

LARUS Foundation explores this concept in What Is Network Identity and Why Does It Matter?.

Continuity planning attempts to identify these dependencies before a disruption exposes them.

IP Address Continuity Is Not the Same as Network Uptime

A company can have excellent server redundancy and still have weak number-resource continuity.

Imagine an enterprise operates:

• two data centres;
• redundant firewalls;
• multiple cloud regions;
• duplicate databases;
• and several upstream providers.

But only one former employee has access to the registry account controlling the company's IP resources.

Or the business has redundant BGP connectivity but nobody has documented the current RPKI ROAs.

Or every critical customer has allowlisted addresses belonging to a provider that the enterprise plans to leave.

The infrastructure may be redundant.

The resource-control model is not.

This is why network continuity planning should examine both:

physical and routing availability

and:

administrative control of the resources on which those systems depend.

Step 1: Build a Complete Internet Number Resource Inventory

The first continuity requirement is visibility.

An enterprise should know exactly which Internet number resources it depends on.

The inventory should include:

For each resource, the enterprise should also record:

• who is responsible;
• why the resource is required;
• where it is deployed;
• which systems depend on it;
• which external parties recognise it;
• and what would happen if it changed.

A spreadsheet may be enough for a small environment.

Larger networks generally benefit from a dedicated IP Address Management system.

Step 2: Identify Which Resources Are Business-Critical

Not every IP address has the same continuity value.

Consider two public IP addresses.

The first supports a temporary testing server.

The second is used by:

• 200 enterprise customers;
• several banking partners;
• payment gateways;
• security allowlists;
• and a production API.

Technically, both are IPv4 addresses.

Operationally, they have very different continuity requirements.

Enterprises should therefore classify resources according to business impact.

A simple model might be:

Critical

Loss or renumbering could disrupt customers, revenue, security or core operations.

Important

A change would require significant coordination but could be managed within days.

Standard

Addresses can be changed with limited operational impact.

This classification helps determine recovery priorities.

Step 3: Document Registry Access

A surprising amount of continuity risk can sit inside an administrative account.

An enterprise should know:

• which registry maintains each resource;
• which organisation account controls it;
• who has administrative access;
• which email addresses are registered;
• how multifactor authentication works;
• who can recover the account;
• and whether access depends on one employee.

A continuity plan should not rely on:

one person

one mailbox

or:

one authentication device.

At least two appropriately authorised people should understand the access process for critical resources.

Credentials should be managed under the organisation's normal privileged-access and security procedures.

Step 4: Keep Registry Records Accurate

Continuity becomes harder when registration information no longer reflects operational reality.

Common problems include:

• former employees listed as contacts;
• outdated company addresses;
• abandoned email accounts;
• old phone numbers;
• incorrect organisation information;
• undocumented corporate changes;
• and obsolete technical contacts.

LARUS Foundation explains why these shared records matter in Why Accurate Registry Data Supports a Stable Internet.

Registration data should be reviewed periodically rather than only when a transfer or incident occurs.

The goal is straightforward:

A continuity plan should not discover during an emergency that the organisation's recovery contact left three years ago.

Step 5: Understand the Difference Between Registry Data and IPAM

Registry data and internal IP Address Management solve different problems.

A public registry might record:

203.0.113.0/24

But the enterprise's internal IPAM system may show:

The registry does not need to describe every internal subnet.

But the enterprise needs its own reliable source of truth.

Continuity planning should therefore preserve both:

external registration accuracy

and:

internal operational accuracy.

LARUS Foundation explains this distinction further in What Is IP Address Registration?.

Step 6: Document BGP Dependencies

Enterprises operating their own ASN should document how their prefixes reach the Internet.

At minimum, the continuity record should include:

• upstream providers;
• BGP neighbours;
• announced prefixes;
• accepted routes;
• routing policies;
• Local Preference;
• BGP communities;
• traffic-engineering rules;
• backup paths;
• and expected failover behaviour.

This matters because an ASN by itself does not create connectivity.

The routing relationships around it do.

An operator should be able to answer:

Which providers currently announce our routes?

Which prefix is announced through which provider?

What happens when one session fails?

Which route is intended to become active?

Are the backup paths actually tested?

For multihomed environments, LARUS Foundation's BGP Multihoming guide explains the relationship between multiple upstreams, routing diversity and resilience.

Step 7: Include RPKI in the Continuity Plan

Resource Public Key Infrastructure has become an important part of Internet routing security.

RPKI allows a resource holder to publish cryptographically verifiable information authorising an ASN to originate a particular prefix.

The architecture is described in RFC 6480.

For continuity planning, the enterprise should document:

• which prefixes have ROAs;
• which ASN is authorised;
• the configured maximum prefix length;
• who can modify the ROAs;
• which account controls the RPKI system;
• and what must change during a routing migration.

This becomes especially important during provider changes or ASN migrations.

Suppose an enterprise changes the origin ASN for a prefix but forgets to update the corresponding ROA.

The new route can appear RPKI Invalid.

Networks performing Route Origin Validation may then reject or de-preference it.

A continuity plan should therefore treat RPKI changes as part of the migration process, not as an afterthought.

LARUS Foundation's RPKI Adoption in 2026 provides more background on route-origin validation.

Step 8: Document IRR Objects and Routing Filters

Many operators also use Internet Routing Registry data when building routing policies and prefix filters.

An enterprise should understand which IRR objects relate to its network.

These may include:

• route objects;
• route6 objects;
• aut-num objects;
• AS sets;
• and related routing-policy records.

During a continuity event, stale IRR data can create unexpected problems.

For example:

• a new provider may generate filters from IRR data;
• a newly announced prefix may not appear in the expected object;
• or an old ASN may remain associated with a route object.

RPKI and IRR are not the same system.

Both may influence whether routing information is accepted by other networks.

That makes both relevant to continuity planning.

Step 9: Protect Reverse DNS Continuity

Reverse DNS is easy to overlook until something stops working.

Public address space can have reverse-DNS delegations associated with it.

These may matter for:

• mail systems;
• logging;
• security investigations;
• network tools;
• reputation systems;
• and operational troubleshooting.

An enterprise should document:

• which reverse zones exist;
• where they are delegated;
• which authoritative servers host them;
• who controls those servers;
• and what happens if a prefix moves.

A network migration that preserves the IP addresses but breaks reverse DNS may still cause operational problems.

Step 10: Map External Allowlists

One of the biggest hidden continuity risks is outside the organisation.

An enterprise may know where its IP addresses are used internally.

It may not know how many external organisations depend on them.

Public IP addresses are frequently added to:

• partner firewalls;
• customer allowlists;
• banking systems;
• SaaS applications;
• API controls;
• cloud security groups;
• VPN policies;
• fraud systems;
• and authentication systems.

These dependencies may have accumulated over many years.

Before renumbering or changing providers, an enterprise should build an external dependency register.

For each critical address or prefix, ask:

Which third parties recognise this address?

Who owns the relationship?

How long would an update take?

Is there a maintenance window?

Can old and new addresses operate simultaneously during migration?

This information can significantly change the realistic duration of a network transition.

Step 11: Include Firewall and Security Dependencies

IP addresses can also be embedded throughout internal security infrastructure.

Examples include:

• firewall rules;
• ACLs;
• SIEM correlation;
• IDS/IPS policies;
• VPN configurations;
• zero-trust policies;
• authentication rules;
• logging;
• and security monitoring.

A renumbering plan that updates routers but forgets security policies may create an outage even when BGP is functioning correctly.

For critical prefixes, enterprises should know where address-based security rules exist.

Step 12: Plan for Provider Exit

A continuity plan should consider what happens when an organisation needs to leave a provider.

Reasons might include:

• pricing;
• service quality;
• acquisition;
• data-centre migration;
• cloud migration;
• geographic expansion;
• network redesign;
• or provider failure.

The key question is whether the organisation's network identity can move independently from the delivery provider.

Provider-independent address space and an enterprise ASN can offer more flexibility in some architectures.

Provider-assigned addresses may create greater renumbering dependency.

Neither architecture is universally correct.

But the dependency should be understood before a provider change becomes urgent.

LARUS Foundation examines the broader continuity implications in Why IP Address Portability Matters for Network Operators.

Step 13: Plan for Cloud Migration

Cloud adoption creates another continuity challenge.

An enterprise may operate public addresses across:

• on-premises infrastructure;
• colocation;
• public cloud;
• private cloud;
• CDN platforms;
• and edge services.

Migration decisions can affect:

• BGP;
• address ownership;
• BYOIP;
• DNS;
• geolocation;
• RPKI;
• security policies;
• and customer allowlists.

Before moving a service, operators should determine whether:

the application is moving

or:

the network identity is also changing.

Those are different projects.

Moving compute while preserving public network identity can reduce external change.

Renumbering the application at the same time can create substantially more coordination work.

Step 14: Include Mergers and Acquisitions

Mergers and acquisitions can expose weak number-resource documentation.

Two companies may suddenly discover they have:

• overlapping internal addressing;
• separate ASNs;
• different registry accounts;
• different RPKI systems;
• duplicate routing policies;
• different IPAM tools;
• and undocumented historical allocations.

Internet number-resource due diligence should therefore be part of infrastructure due diligence.

Questions should include:

• What IPv4 resources exist?
• What IPv6 resources exist?
• Which ASNs exist?
• Which organisation is registered?
• Which resources are transferable?
• Who controls registry access?
• What ROAs exist?
• What IRR objects exist?
• What external dependencies exist?
• Which prefixes have poor reputation history?
• Which resources are actually being used?

This can prevent an acquisition from inheriting resources that nobody can properly administer.

Step 15: Plan for Staff Turnover

Infrastructure continuity should never depend on one engineer.

A common risk pattern looks like this:

Senior network engineer creates architecture
↓
Engineer manages registry account
↓
Engineer controls RPKI
↓
Engineer maintains BGP configuration
↓
Engineer leaves company

The infrastructure may continue running normally.

Until something needs to change.

Enterprises should maintain:

• documented procedures;
• shared privileged-access controls;
• clear ownership;
• succession planning;
• recovery contacts;
• and periodically tested access.

No critical resource should become effectively unmanageable because one employee leaves.

Step 16: Treat IP Reputation as a Continuity Dependency

Technical routing continuity does not automatically guarantee application continuity.

Public IP addresses also accumulate external reputation.

Third-party systems may classify addresses based on:

• historical spam;
• abuse;
• scanning;
• malware;
• email behaviour;
• hosting activity;
• geolocation;
• and previous users.

When an enterprise acquires, leases or reuses address space, it should check:

• major blocklists;
• geolocation databases;
• email reputation;
• abuse history;
• and routing history.

A prefix can be technically routable while still creating application-level problems.

This means continuity testing should consider reachability and reputation.

Step 17: Define Recovery Time Objectives for Number Resources

Enterprises routinely define Recovery Time Objectives for applications.

The same thinking can be applied to network-resource dependencies.

For example:

The exact targets depend on the organisation.

The value of the exercise is forcing teams to decide what must be restored first.

Step 18: Separate Technical Failure From Administrative Failure

Continuity plans often focus on physical failures.

For Internet number resources, administrative failures can be equally important.

Technical Failure

Examples:

• router failure;
• fibre cut;
• provider outage;
• BGP session failure;
• data-centre outage.

Administrative Failure

Examples:

• registry account inaccessible;
• expired organisational contact;
• lost MFA device;
• incorrect RPKI configuration;
• unavailable authorised signatory;
• undocumented company restructuring;
• expired contract.

The network may remain physically functional during an administrative failure.

But the organisation may become unable to safely change, transfer or secure its resources.

A mature plan prepares for both categories.

Step 19: Create a Number Resource Source of Truth

Every enterprise should know where authoritative internal information about its number resources lives.

That system might be:

• IPAM;
• a CMDB;
• a dedicated registry database;
• or a controlled combination of systems.

The source of truth should identify:

Resource
What prefix or ASN is this?

Authority
Who controls it?

Registry
Where is it recorded?

Routing
Where is it announced?

Security
What ROA or IRR records apply?

Dependency
Which systems and customers use it?

Owner
Which team is accountable?

Recovery
What happens if something fails?

Without this structure, critical information tends to become distributed across email, spreadsheets, router configurations and individual memory.

That is difficult to recover during an incident.

Step 20: Test the Continuity Plan

A continuity document that has never been tested is an assumption.

At least annually, enterprises should test scenarios such as:

Scenario 1: Loss of One Upstream Provider

Can traffic fail over as expected?

Scenario 2: Loss of Registry Account Access

Can authorised staff recover access?

Scenario 3: RPKI Misconfiguration

Can the team identify and correct an Invalid route?

Scenario 4: Network Engineer Departure

Can another team member perform critical procedures?

Scenario 5: Provider Migration

Can the network change connectivity without unexpectedly changing critical public identity?

Scenario 6: Data Centre Failure

Can prefixes still be announced from another site?

Scenario 7: Renumbering

Does the organisation know every customer, application and security policy that must change?

These tests expose hidden dependencies before a real incident does.

A Practical Enterprise Continuity Checklist

A strong annual review should confirm the following.

Resource Inventory

• All IPv4 prefixes are documented.
• All IPv6 prefixes are documented.
• All ASNs are documented.
• Provider-assigned resources are clearly identified.
• Provider-independent resources are clearly identified.

Registry

• Organisation information is current.
• Administrative contacts are current.
• Technical contacts are current.
• Recovery contacts work.
• More than one authorised person can access critical accounts.
• Multifactor authentication recovery is documented.

Routing

• BGP peers are documented.
• Routing policies are backed up.
• Upstream dependencies are known.
• Failover has been tested.
• Physical path diversity has been verified.

Routing Security

• ROAs are reviewed.
• Origin ASNs are correct.
• Maximum prefix lengths are intentional.
• IRR objects are current.
• Routing filters are documented.

DNS

• Reverse DNS delegations are documented.
• Authoritative servers are known.
• Recovery procedures exist.

Internal Operations

• IPAM is current.
• Critical address use is documented.
• Firewall dependencies are recorded.
• Monitoring covers critical prefixes.

External Dependencies

• Customer allowlists are known.
• Partner allowlists are known.
• API dependencies are documented.
• Cloud dependencies are known.
• IP reputation is monitored.

People

• No critical process depends on one employee.
• Documentation is accessible.
• Privileged credentials are managed securely.
• Responsibility is clearly assigned.

What Should Enterprises Prioritise First?

An organisation beginning this process does not need to solve everything in one project.

A practical starting order is:

1. Know what resources exist.

2. Know who controls them.

3. Know where they are used.

4. Know which external systems depend on them.

5. Verify registry and RPKI access.

6. Document BGP and provider dependencies.

7. Test one realistic failure scenario.

This creates immediate visibility into the highest-impact risks.

Frequently Asked Questions

What is IP address continuity?

IP address continuity is the ability to maintain reliable operational use and management of important IP address resources during infrastructure, provider, administrative or organisational changes.

What is ASN continuity?

ASN continuity means ensuring an organisation retains the ability to manage its Autonomous System Number, routing relationships and related records when personnel, providers or infrastructure change.

Why should enterprises include IP addresses in business continuity planning?

Public IP addresses can become embedded in customer allowlists, APIs, security policies, VPNs, BGP, DNS and external systems. Losing or unexpectedly changing them can therefore cause business disruption.

What should an IP address continuity plan include?

It should include IPv4 and IPv6 inventories, registry access, ASN information, BGP configuration, RPKI, IRR, reverse DNS, IPAM, security dependencies, external allowlists and recovery responsibilities.

Is IPAM enough for continuity planning?

No. IPAM is an important internal source of truth, but it does not replace registry records, BGP configuration, RPKI, IRR, DNS or documentation of external dependencies.

How does RPKI affect continuity?

If ROAs do not match the intended prefix and origin ASN after a routing change, legitimate announcements may become RPKI Invalid. RPKI changes should therefore be included in migration and recovery procedures.

Why is registry access a business continuity issue?

If an organisation cannot access the account administering its resources, it may be unable to update contacts, manage RPKI, complete transfers or respond effectively to operational changes.

What happens if the network engineer managing the ASN leaves?

The organisation should already have documented access, configuration backups, recovery procedures and other authorised personnel able to manage the resources.

Why are customer allowlists important?

Customers and partners may permit traffic only from known IP addresses. Changing those addresses can break connectivity until external parties update their systems.

Does having two ISPs solve number-resource continuity?

No. Multiple ISPs improve connectivity resilience, but continuity also depends on addressing, ASN control, registry access, routing security and underlying physical diversity.

Should enterprises test IP address continuity?

Yes. Testing exposes hidden dependencies such as inaccessible accounts, outdated contacts, incorrect ROAs, untested failover and undocumented allowlists.

Conclusion

Internet number resources should not be treated as background administrative details.

For many enterprises, IPv4 addresses, IPv6 prefixes and ASNs have become part of critical infrastructure.

They connect applications.

They identify networks.

They appear in security policies.

They are recognised by customers and partners.

They support routing.

And over time, they can become embedded in the organisation's operational identity.

That means continuity requires more than keeping routers online.

An enterprise also needs to preserve:

visibility

control

accurate records

routing capability

security authorisations

and:

knowledge of external dependencies.

The strongest continuity plan therefore connects several layers:

registry records

→ IPAM

→ BGP

→ RPKI and IRR

→ DNS

→ security systems

→ customer and partner dependencies

→ documented recovery procedures

No single system replaces the others.

The goal is not to centralise every operational detail into one external database.

It is to ensure that each layer contains accurate information and that the organisation knows how those layers depend on one another.

For enterprises, the most important continuity question is therefore not simply:

“Do we still have Internet connectivity?”

It is:

“Can we still identify, control, route, secure and recover the Internet number resources on which our operations depend?”

If the answer is clearly documented and regularly tested, IPv4, IPv6 and ASN resources become part of a resilient infrastructure strategy rather than an undocumented operational dependency.