IPv4 Renumbering Planner

Maintenance window:

Use the date, start/end time, and timezone from the change record.

Window length: {{ params.windowMinutes }} minutes

Include implementation, validation, and DNS cache soak time.

minutes

Wave size: {{ params.waveSize }} hosts

Smaller waves are easier to validate and roll back when dependencies are uncertain.

hosts

Old prefix boundary:

Example: 10.10.0.0/16. Leave blank to skip the old-prefix audit.

New prefix boundary:

Example: 10.44.0.0/16. Leave blank to skip the new-prefix audit.

Default cutover method:

Choose the safest normal path for this renumbering window.

Target DNS TTL: {{ params.dnsTtlMinutes }} minutes

Set the TTL that will be in place before the first wave starts.

minutes

Target DHCP lease: {{ params.dhcpLeaseHours }} hours

Use the lease duration planned for affected DHCP-backed hosts.

hours

Implementation time per host: {{ params.perHostMinutes }} minutes

The timeline multiplies this by each wave's host count.

minutes

Validation time per wave: {{ params.validationMinutes }} minutes

Critical rows add a small extra validation allowance automatically.

minutes

Host mappings:

Paste one row per host. Dependencies that match another host are sequenced first.

CSV columns: host, old_ip, new_ip, owner, dependency, criticality, method.

Rollback trigger:

Keep this executable during the window, not just a general risk note.

{{ header }}	Copy
{{ cell }}
No {{ tab.label.toLowerCase() }} rows Paste host mappings or load the sample rows before exporting this table.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

IPv4 renumbering changes the addresses a network uses for hosts, services, routes, and operational tooling. The interface edit is only one visible part. Names, reverse DNS records, DHCP reservations, firewall rules, NAT policies, monitoring checks, backup jobs, configuration files, route filters, certificates with pinned addresses, and partner allowlists can keep referring to the old address long after the host has moved.

Most of the risk is decided before the maintenance window starts. A useful plan names every old-to-new mapping, the owner who can approve the move, the systems that must move first, and the tests that prove each wave is safe to continue. Without that preparation, the window turns into a search exercise: teams find stale DNS records, unreachable management paths, duplicate assignments, or application dependencies while users are already exposed to the change.

Mapping: A host-level pair that connects an existing IPv4 address to the planned replacement address.
Prefix boundary: The approved CIDR block that old or new addresses are expected to stay within, such as 10.10.0.0/16.
Wave: A small batch of hosts changed together so validation and rollback stay manageable.
Soak time: A planned wait after DNS or routing changes so caches, clients, and monitors can reveal stale references.
Rollback trigger: A concrete condition that stops the current wave and returns affected hosts to the old addressing plan.

Renumbering often appears during mergers, subnet consolidation, cloud migrations, provider changes, overlapping private-address cleanup, lab-to-production moves, and public-to-private or private-to-public transitions. Each case has a different risk profile. A private address move may be mostly local, but it can still break VPNs, ACLs, and monitoring. A public address move may require coordination with DNS, routing policy, upstream providers, external customers, and abuse or security controls.

A successful ping or one healthy application check does not prove that renumbering is complete. Reachability matters, but it does not prove that clients have stopped using old DNS answers, that reverse records changed, that alerting points to the new address, or that future failover will still work. A stronger closeout requires the address mapping and the operational evidence to agree.

How to Use This Tool:

Use the planner to turn a host mapping worksheet into an execution-ready draft. It works best when the CSV comes from a reviewed change record, IP address management export, or service inventory rather than a hand-built list assembled during the window.

Enter the Maintenance window, Window length, Wave size, target DNS TTL, target DHCP lease, implementation time per host, and validation time per wave.
Paste one host mapping per CSV row. The expected columns are host, old IP, new IP, owner, dependency, criticality, and method. Use Load sample only as a shape reference, then replace it with real rows.
Use Normalize CSV after pasting from a spreadsheet or change ticket when spacing and quoting look uneven. If required columns are missing, fix the source rows before using the generated runbook.
Add Old prefix boundary and New prefix boundary when the change must stay inside approved CIDR blocks. Rows outside those boundaries are marked for review.
Choose the Default cutover method. Override individual CSV rows when a host needs a DHCP reservation move, DNS alias move, direct static cutover, or parallel old-and-new address approach.
Open Advanced and enter a specific rollback trigger. A useful trigger names the failed evidence, retry count, owner sign-off, or go/no-go condition for the current wave.
Review Wave Runbook, Mapping Ledger, Readiness Audit, Cutover Timeline, Rollback Pack, and JSON. Copy or download the outputs that belong in the change record, and do not proceed while any blocked finding remains unresolved.

Interpreting Results:

The readiness summary uses three practical states. Ready means the supplied rows and timing values passed the worksheet checks. Watch means the plan can still be usable, but a human owner should review the evidence before execution. Blocked means at least one condition should be fixed before the change proceeds.

Blocked findings include invalid IPv4 addresses, duplicate old or new addresses, invalid CIDR boundary input, dependency cycles, DNS TTL values above 60 minutes, DHCP lease values above 24 hours, or a planned elapsed time longer than the maintenance window. Watch findings include duplicate host names, rows outside valid prefix boundaries, TTL above 15 minutes, DHCP lease above 4 hours, direct static cutovers, missing rollback criteria, and common static-reference keywords in dependency text.

IPv4 renumbering result areas
Result area	What it answers	Review before the window
Wave Runbook	Which gate, host, and hold steps belong in each wave.	Owner names, dependency order, method-specific action text, and hold points.
Mapping Ledger	How each old address maps to a new address, owner, dependency, criticality, and method.	Duplicate addresses, invalid addresses, scope changes, and prefix exceptions.
Readiness Audit	Which checks are Ready, Watch, Blocked, or Info and who owns the next action.	Blocked rows first, then watch rows assigned to DNS, DHCP, IPAM, application, or change owners.
Cutover Timeline	How implementation, validation, DNS soak, and cumulative elapsed time fit against the window.	Any wave that consumes too much recovery time or crosses the approved window line.
Rollback Pack	What trigger, revert action, validation step, and owner apply to each wave.	Whether the trigger is concrete enough for a live go/no-go decision.

The timeline is a planning budget, not a live network measurement. It does not query DNS, renew DHCP leases, test firewalls, prove routing convergence, or verify application health. Use it to decide whether the proposed wave size and soak time are plausible, then pair it with real pre-check and post-check evidence.

Technical Details:

IPv4 addresses are four-octet, 32-bit values. CIDR boundaries use a prefix length from /0 through /32, then compare each address against the calculated network and broadcast range. A boundary mismatch is a review signal because the address may be an approved exception, a wrong prefix, or a row copied from the wrong source list.

Address scope labels are context clues, not routing proof. Private, shared, link-local, loopback, documentation, and public-looking ranges carry different operational expectations in the IANA special-purpose registry and the RFCs that define those ranges. Moving between scopes deserves extra review because DNS visibility, NAT behavior, security policy, and provider routing can change even when the host's service role stays the same.

IPv4 address scope labels used during renumbering review
Scope label	Range family	Planning meaning
Private	`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`	Usually enterprise-local or NAT-backed, but overlaps with partners, VPNs, and mergers can still break routing.
Carrier-grade NAT	`100.64.0.0/10`	Shared address space needs provider or edge-design review before it is treated like ordinary private space.
Link-local	`169.254.0.0/16`	Useful only on the local link in normal use; it is a warning sign in planned routed addressing.
Loopback	`127.0.0.0/8`	Represents local host behavior and normally should not appear as a reachable service mapping.
Documentation	`192.0.2.0/24`, `198.51.100.0/24`, `203.0.113.0/24`	Reserved for examples; seeing these in production rows usually means sample data was not replaced.
Public-looking	Any parsed address outside the listed special ranges	May require provider routing, public DNS, external allowlist, abuse desk, and certificate checks.

Dependency ordering uses host names mentioned in dependency text. When one row names another host, the named dependency is placed earlier if possible. Unmatched dependency text is still useful because it often names DNS, firewall, load balancer, monitoring, replication, VPN, or owner checks. A circular dependency blocks automatic ordering because no sequence can satisfy both sides at once.

Formula Core:

For wave w, n_w is the host count, c_w is the number of high or critical rows, t_host is implementation minutes per host, t_validate is base validation minutes per wave, and t_dns is DNS soak time.

\begin{array}{lll} I_{w} & = & n_{w} \times t_{host} \\ V_{w} & = & t_{validate} + 5 \times c_{w} \\ W_{w} & = & I_{w} + V_{w} + t_{dns} \\ T_{k} & = & \sum_{w = 1}^{k} W_{w} \end{array}

IPv4 renumbering readiness thresholds
Check	Ready or Info	Watch	Blocked
Mapping inventory	At least one row is parsed with the required fields.	Not used for this check.	No usable mappings or rows with too few CSV columns.
IPv4 syntax	Every old and new address parses as IPv4.	Not used for this check.	One or more old or new addresses are invalid.
Uniqueness	No duplicate old-address or new-address sets are found.	A host name appears more than once.	An old or new IP address appears more than once.
Prefix boundaries	Valid boundaries contain the checked addresses, or no optional boundary is set.	At least one row sits outside a valid old or new prefix boundary.	An entered CIDR boundary is invalid.
Dependency sequencing	Matched host dependencies can be placed before dependents, or no host dependency is matched.	Unmatched text remains a manual checklist item.	A dependency cycle is found.
DNS TTL	15 minutes or less.	More than 15 minutes and up to 60 minutes.	More than 60 minutes.
DHCP lease	4 hours or less.	More than 4 hours and up to 24 hours.	More than 24 hours.
Window fit	Total estimated time uses 85% or less of the approved window.	Total estimated time uses more than 85% of the window.	Total estimated time exceeds the window.
Rollback criteria	A rollback trigger is supplied.	No rollback trigger is supplied.	Not used for this check.

Cutover method changes the operational risk. A parallel move can prove the new address before retiring the old one, but it needs routing, DNS, and allowlists that tolerate overlap. A DHCP move depends on reservation or scope changes and client renewal behavior. A DNS alias move depends on record timing and dependency shift. A direct static move needs the strongest console or out-of-band path because a bad edit can strand the host.

Limitations and Privacy:

The planner does not scan live hosts, test reachability, query DNS, renew DHCP leases, update firewall rules, change routes, or modify device configuration.
Planning calculations run in the browser. Host names, owner names, dependencies, and address plans should still be treated as sensitive change-control material when pasted, copied, downloaded, or shared.
DNS and DHCP timing are simplified planning inputs. Resolver caching, stale records, relay behavior, lease renewal timing, failover services, and client reboot windows can extend the real change duration.
Dependency text is not service discovery. Confirm application, firewall, monitoring, backup, replication, and management dependencies with the owners who operate them.
A Ready result means the supplied plan passed worksheet checks. It does not approve the change, replace CAB review, or prove that production traffic will follow the new path.

Worked Examples:

IPv4 renumbering planning examples
Scenario	Input pattern	Result to review
Application stack move	The database host is named as a dependency for application hosts, and the database row is marked high or critical.	Confirm the database appears in an earlier wave and that validation time includes the criticality buffer.
DHCP-backed client move	Many rows use the DHCP method, and the target lease value is several hours long.	Expect a lease watch item and plan reservation changes, lease reduction, renewal, or reboot steps before the wave.
Static server cutover	Several critical rows use direct static cutover.	Confirm console access, reversible commands, DNS/PTR updates, allowlists, monitoring checks, and owner sign-off.
Prefix exception review	A row's old or new address sits outside the entered CIDR boundary.	Decide whether the row is an approved exception, a typo, or evidence that the boundary itself is wrong.

FAQ:

Can the planner discover dependencies automatically?

No. It uses the dependency text you provide. Service owners, monitoring records, firewall rules, DNS records, backup jobs, and application documentation still need review.

Why can DNS TTL make a plan blocked?

A long TTL can make a short window unrealistic because resolvers may keep old answers after hosts move. Lower the TTL before the window, add soak time, or schedule a longer change.

Why is a direct static cutover only a watch item?

Some systems genuinely need a direct edit. The watch item means the row needs stronger access and rollback evidence because a wrong static address can make the host unreachable.

Does Ready mean the network is safe to change?

No. Ready means the supplied rows and timing values passed planning checks. Live route, DNS, DHCP, firewall, service, and owner validation still control the real change.

Glossary:

CIDR: Classless Inter-Domain Routing notation, such as 10.44.0.0/16, that describes an address block by prefix length.
DNS TTL: Time to live for a DNS answer. Higher values can keep stale records visible for longer after a renumbering change.
DHCP lease: The time a client can keep a dynamically assigned address before renewal or rebinding behavior matters.
PTR record: A reverse DNS record that maps an IP address back to a name. Renumbering often needs both forward and reverse DNS updates.
Out-of-band access: A management path that does not depend on the address being changed, such as a console, BMC, serial path, or separate management network.

IPv4 Renumbering Planner

Introduction:

How to Use This Tool:

Interpreting Results:

Technical Details:

Formula Core:

Limitations and Privacy:

Worked Examples:

FAQ:

Glossary:

References: