IPv6 NAT explained: the end of NAT and direct connections

By ColossusCloud's Team

March 9, 2026

The relationship between IPv6 and NAT is simple: IPv6 doesn’t need it. NAT (Network Address Translation) was never part of the original internet design. It was bolted on in the 1990s as a workaround for IPv4 running out of addresses. Give a household or office one public IP, hide many devices behind it, rewrite packet headers on the way out. It worked, mostly, and now we’re stuck with the consequences.

IPv6 makes NAT obsolete. With 128-bit addresses, every device can have its own globally unique, publicly routable address. No sharing, no translation, no port forwarding. The original internet model restored.

Why IPv4 needed NAT

IPv4 has roughly 4 billion addresses. By the 1990s, the internet was outgrowing that. The fix: network operators started assigning one public address to a gateway, then running a private address space (10.0.0.0/8, 192.168.0.0/16) inside. The gateway rewrites outbound packet headers, tracks connection state, and rewrites responses on the way back in.

This worked, but it broke the symmetric internet:

  • Port forwarding to run any server behind NAT
  • STUN and TURN servers for VoIP, video calls, and anything peer-to-peer
  • Hole-punching in P2P software that succeeds maybe 80% of the time
  • Relay services that add cost and latency to every connection
  • Carrier-grade NAT (CGNAT) where even the gateway is behind NAT, making inbound essentially impossible
  • IPv4 address scarcity driving prices to $30-50 per address and climbing

None of this is fundamental to how networking works. It’s all NAT workarounds.

Does IPv6 use NAT?

Short answer: no, not in the traditional sense. IPv6 has so many addresses (128-bit = ~340 undecillion total) that there’s no scarcity to work around. Every device, container, service, and IoT sensor can have its own public address with room to spare.

There are a few IPv6 address translation mechanisms (NPTv6, NAT64), but they exist for specific interop scenarios, not because IPv6 “needs” NAT. For the vast majority of deployments, IPv6 means no NAT.

What end-to-end connectivity actually means

In the original internet design, any device can initiate a connection to any other device. That’s end-to-end connectivity, and it’s how protocols like FTP, SIP, IRC, and BitTorrent were designed to work.

IPv6 restores this:

  • Your VPS is directly reachable on its IPv6 address. No port forwarding, no NAT rules.
  • IoT devices at customer sites can receive inbound connections directly (if the ISP supports IPv6, and most do now).
  • Peer-to-peer works. Two IPv6 devices can connect directly without STUN servers.
  • Each container or service can have its own public IPv6 address, reachable individually.
  • No NAT state tables. Fewer moving parts, less connection tracking overhead.

IPv6 vs NAT: a concrete example

Running a game server from home with IPv4:

  1. Pick a port (Minecraft = 25565)
  2. Log into the router
  3. Configure port forwarding: external 25565 → internal 192.168.1.50:25565
  4. Find your public IPv4 (may change if the ISP doesn’t give you a static one)
  5. Share IP:port with friends
  6. Pray your ISP doesn’t use CGNAT

Running the same server with IPv6:

  1. Start the server, listen on IPv6
  2. Share the IPv6 address with friends
  3. Done

The IPv6 address is globally unique and routable. No router config, no NAT traversal.

What this means for developers

If you build distributed systems, IoT fleets, or P2P applications, removing NAT from the equation simplifies your architecture. No more:

  • Running TURN servers for NAT-restricted clients
  • Maintaining port forwarding rules on customer networks
  • Paying relay services to sit between peers
  • Fighting CGNAT in mobile deployments

On your ColossusCloud VPS, enabling IPv6 means your server is a first-class internet citizen again. Not hiding behind NAT, not paying for extra IPv4, not limited to outbound-only.

The dual-stack reality

You can’t fully drop IPv4 yet. Some networks still don’t have IPv6, and some services advertise only IPv4. The practical approach is dual-stack: run both in parallel. Use IPv4 for clients that need it, use IPv6 everywhere else. Over time the IPv4 dependency shrinks.

For new projects, design IPv6-first. You’ll avoid NAT altogether on the IPv6 side and save money by not needing extra IPv4 addresses.

Getting started

Every ColossusCloud VPS includes IPv6. Enable it through the Client Portal, request a routed /56 for subdividing across services or device fleets, and build like NAT was never a thing.

Deploy a VPS with IPv6 and leave the NAT era behind.

← Back to all articles