Every time your team opens a warehouse, onboards a 3PL partner, or rolls out autonomous mobile robots on a production floor, someone has to answer a simple network question: what IP addresses will this site use?

For years, that question had an easy answer. You grabbed a block of addresses, configured your routers, and moved on. Today, the math has changed. The central pool of IPv4 addresses has been empty for more than a decade, many regional registries have exhausted their normal supply, and common workarounds now create real friction for site launches, partner integrations, and field-service operations.

This article explains where scarcity affects supply chain network planning, which workarounds help, which ones shift the pain elsewhere, and how to build a practical addressing strategy that keeps projects moving.

What IPv4 Scarcity Means in 2026

IPv4 addresses are the 32-bit numbers that identify devices on a network. There are roughly 4.3 billion of them. That sounded like plenty in the 1990s, but it is not enough for a world full of sensors, telematics units, cloud services, and connected forklifts.

The central free pool managed by IANA was depleted on February 3, 2011. After that, each Regional Internet Registry handed out its remaining stock on its own timeline. APNIC, which covers the Asia-Pacific region, moved to its final reserve in 2011. ARIN, which covers the US and Canada, reached depletion in 2015. RIPE NCC, covering Europe and parts of the Middle East, ran out of its available IPv4 pool in 2019.

IPv6 adoption is growing, but progress is uneven. Google measurements have shown global IPv6 traffic approaching half of user traffic, and the US federal government has pushed agencies toward IPv6-only environments through OMB Memorandum M-21-07. Those signals matter, but they do not remove IPv4 from partner networks, field devices, or older warehouse systems.

For supply chains, the issue is bigger than the internal network. Every carrier integration, 3PL extranet, and vendor remote-access session depends on IP addresses routing correctly across organizations. When address ranges are scarce, hidden behind translation, or overlapping with a partner’s network, those connections become harder to plan and support.

Where Scarcity Bites Supply Chain Network Planning

Addressing problems usually appear at the boundaries between companies, sites, carriers, cloud platforms, and remote equipment. These are the areas planners should review before a rollout date is set.

Mergers, Acquisitions, and 3PL Onboarding

When two companies merge, or when you onboard a new logistics partner, their internal networks often use private IPv4 ranges defined by RFC 1918, such as 10.0.0.0/8 or 192.168.0.0/16. The problem is that both sides may have chosen the same ranges independently. Cisco documents that overlapping private address space is common during mergers and can be mitigated with Network Address Translation, or NAT, though NAT adds complexity to routing, VPN tunnels, and SD-WAN policies.Renumbering one side to remove the overlap is expensive and risky. It can take months of change-control windows and after-hours cutovers. NAT can bridge the gap, but it can also obscure which device is talking to which system. For a supply chain team trying to get a new 3PL site live on a warehouse management system in weeks, not months, that delay is a real blocker.

Remote Sites, Telematics, and Robotics

Field sites, distribution yards, and mobile fleets often sit behind carrier-grade NAT, or CGNAT. RFC 6598 reserves a special address block, 100.64.0.0/10, for these deployments, where the carrier shares a smaller pool of public addresses among many customers. This works for outbound browsing and routine application traffic, but it can break inbound connections. That limitation is important when planning mobile technology in supply chains across yards, vehicles, and warehouse equipment.

That matters when a robotics vendor needs to diagnose a palletizer remotely, or when a telematics platform needs to push firmware updates to trailer sensors. Workarounds exist, including persistent tunnels and cloud relay services, but they add latency, operational complexity, and support cost.
For organizations planning technology infrastructure alongside logistics operations, addressing should be part of the broader IT roadmap rather than a late-stage network task.

Cloud and SaaS Dependencies

Cloud providers are also sending clear pricing signals about IPv4 scarcity. AWS began charging $0.005 per hour for each public IPv4 address on February 1, 2024. That works out to roughly $43 per address per year. If your supply chain environment runs many cloud-connected services, those costs can add up quickly, especially when control tower software and other visibility tools rely on stable network connections across sites.
The charge exists to encourage customers to adopt IPv6, and it is a useful reminder that holding public IPv4 addresses is no longer free, even in the cloud. Public addresses should be planned, tracked, and justified like any other scarce infrastructure resource.

The Workarounds You Already Use, and Their Trade-Offs

Most organizations already rely on several IPv4 conservation techniques. They are useful, but each one has limits that can show up during partner onboarding, vendor support, and site expansion.

Private IPv4 with NAT

Most enterprise networks use RFC 1918 private address space internally and translate to public addresses at the edge using NAT. This conserves public IPv4 and works well inside a single organization. But the Internet Architecture Board has noted in RFC 2993 that NAT weakens end-to-end connectivity and increases operational complexity.In practice, this means more difficult troubleshooting, fragile VPN configurations, and extra work when connecting with outside partners. NAT is a useful tool, but it should not become the default answer to every integration problem.

Carrier-Grade NAT

CGNAT lets carriers stretch a small pool of public IPv4 addresses across many customers. For branch offices and remote yards, it can keep connectivity costs low. The trade-off is that inbound connections, peer-to-peer tools, and some VPN protocols do not work cleanly behind CGNAT.

If vendor support agreements include remote access service levels, CGNAT can quietly put those commitments at risk. Before choosing a carrier service for a remote site, confirm whether the connection uses CGNAT and what inbound access options are available.

Overlapping Address Space Across Partners

When two partners use the same private ranges, every firewall rule, DNS record, and SD-WAN policy has to account for the collision. Change management gets harder because a simple subnet change on one side can affect the other side. Over time, this technical debt slows onboarding and increases the chance of outages during integration.

When Public IPv4 Still Earns Its Keep

Not every scenario needs public IPv4. In many cases, IPv6, private addressing, proxies, or controlled translation can do the job. A few situations still justify a small, well-governed public IPv4 allocation:

• Securely exposing a limited set of services. If partners or customers need to reach specific endpoints, such as an EDI gateway or an API, a small block of governed public addresses may be simpler than layering multiple proxies and tunnels.
• B2B connections where partners cannot support IPv6. Some trading partners, especially smaller carriers or regional suppliers, may be years away from IPv6 readiness. A handful of public IPv4 addresses can keep those connections working without complicated workarounds.
• Complex multi-tenant extranet setups. When you host portals or data exchanges for multiple partners, unique public addresses can help avoid routing collisions that NAT-heavy designs often create.

The key is governance. Treat public IPv4 as a scarce resource, justify each allocation, document ownership, and plan to reduce dependence over time.

An IPv6-First Plan That Still Respects Reality

IPv6-first does not mean IPv6-only everywhere tomorrow. It means designing new environments around IPv6, then using IPv4 only where a real dependency requires it.

Prioritize Greenfield IPv6-Only Where Feasible

New warehouses, robotics cells, and sensor networks are the easiest places to start fresh with IPv6. The address space is large enough that collisions are effectively removed from the planning problem. Where legacy systems still need IPv4, technologies such as NAT64 and DNS64 can bridge traffic at the network edge without requiring every device to run dual-stack.

Use Dual-Stack for Brownfield and Partner Compatibility

For existing sites, a phased approach works best. Start by inventorying which applications and vendors actually require IPv4. Enable IPv6 on the SD-WAN backbone and campus networks. Extend monitoring, logging, and security controls to cover IPv6 traffic. Then set clear deprecation gates: once a vendor or application supports IPv6, schedule the IPv4 removal.

Set Address Planning Guardrails

A clean address plan prevents the collisions and confusion that slow down site launches. Use the same discipline for IPv6 that you already apply to critical infrastructure:

• Maintain a central registry of all subnets, both IPv4 and IPv6.
• Reserve standard blocks by site type, such as distribution center, cross-dock, and branch office.
• Require change-control approval before assigning new ranges.
• Audit allocations quarterly to reclaim unused space.

Sourcing and Governance for the IPv4 You Still Need

If a public IPv4 block is still needed, treat it like a controlled procurement rather than a quick purchase. The goal is to prove need, verify the address history, and document ownership cleanly.

Use Registry-Based Transfer Channels

When you genuinely need public IPv4, the responsible path is through your Regional Internet Registry’s transfer process. ARIN, for example, supports IPv4 address transfers under policies that require justification and offer pre-approval based on a 24-month demonstrated need.

Due diligence should include confirming clean title, checking whether the block has appeared on major blocklists, verifying routing authorization records such as RPKI and ROA, and updating WHOIS and IRR entries after transfer. Skipping these steps can leave you with addresses that are difficult to route, disputed, or blocked by important partners.

Working with an Advisor

The IPv4 transfer market can be unfamiliar territory for supply chain IT teams that deal with it infrequently. A qualified broker or advisor can help compare sellers, validate address history, and handle registry paperwork. When procurement is necessary, organizations like Buy IPv4 can help navigate provider comparisons and IPv4 transfer workflows.

The important questions are straightforward: Is the block clean? Are there pending disputes? Will the seller cooperate on the registry transfer timeline? Are routing and registry records ready to update as soon as the transfer is approved?

Budget and Risk: Signals to Guide Decisions

Every IPv4-dependent design carries ongoing costs: the addresses themselves, NAT infrastructure, troubleshooting overhead, and downtime risk during renumbering. Cloud cost signals, such as the AWS per-address charge, reinforce that the industry is moving toward IPv6.

Planning your supply chain network with IPv6 as the default reduces long-term friction, simplifies partner onboarding, and cuts the time your team spends on addressing conflicts. It also makes it easier to reserve public IPv4 for the few cases where it still provides clear value.

Conclusion

Address scarcity is not a theoretical problem. It shows up when you integrate a new partner, launch a remote site, connect a fleet of sensors, or merge networks after an acquisition. The practical response is a clear decision pattern: default to IPv6 for new builds, run dual-stack where brownfield systems and partners require it, and maintain a small, tightly governed pool of public IPv4 for the cases that genuinely need it.Keep your address plan clean, audit it regularly, and treat every new allocation as a chance to move closer to a simpler network. That discipline helps supply chain teams move faster without building avoidable addressing problems into the next rollout.

FAQs

These common questions can help teams translate the IPv4 and IPv6 strategy into practical planning decisions.

Do we still need any IPv4 if we are moving to IPv6?

In most cases, yes, at least for now. Some partners, legacy applications, and B2B integrations still require IPv4 connectivity. The goal is to minimize that footprint over time by defaulting to IPv6 for new deployments and setting clear retirement milestones for older systems.

Does CGNAT solve connectivity challenges for telematics and vendor access?

CGNAT helps conserve addresses, but it can break inbound connections that telematics platforms and vendor remote-access tools often rely on. If support agreements include remote diagnostics or firmware updates pushed to field devices, CGNAT may require additional workarounds such as persistent tunnels or cloud-based relay services.

How many public IPv4 addresses should a new site plan for?

As few as possible. Many new sites can operate with zero public IPv4 if they use IPv6 natively and proxy or translate at the edge. For sites that need public-facing endpoints, a /28 or /29 block is often enough when paired with careful service design. Justify each address individually rather than reserving large blocks speculatively.

What if a key partner cannot support IPv6 yet?

Dual-stack is the standard bridge. Run both IPv4 and IPv6 on the links and services that face that partner, while keeping internal and newer segments IPv6-first or IPv6-only where feasible. Set a regular review date to check whether the partner has added IPv6 support so you can retire the dual-stack configuration when it is no longer needed.