Carrier-grade NAT works beautifully until a subscriber wants to be reached. A camera they can view from work, a home server, a self-hosted game server, a site-to-site VPN: all of these need an address the outside world can connect to without the subscriber connecting out first. On a shared public IPv4 that address does not exist. This note sets out the real options and when each one fits.
Why outbound-friendly is not inbound-friendly
Netavo's CGN is permissive for peer-to-peer traffic: it uses endpoint-independent mapping and filtering, so once a subscriber sends out, remote hosts can answer, and gaming and VoIP work (see the note on CGNAT and gaming). But a server waiting for an unsolicited connection has not sent anything out, so there is no mapping for an inbound packet to match. Making that work needs a deliberate mechanism, not a NAT setting.
There are four approaches in the industry, and two of them are the ones to reach for.
IPv6: the answer that removes the problem
On IPv6 there is no NAT and no address sharing. Every device behind the subscriber's router has a globally routable address from the delegated prefix, so inbound reachability is simply a firewall rule on the CPE, exactly as it was in the pre-NAT era. For anything that can speak IPv6 end to end, this is the clean answer and it costs you no scarce IPv4.
The catch is the far end. The person or service connecting in also needs IPv6. That is increasingly common, most mobile networks are IPv6-first, but it is not universal, so IPv6 solves inbound for a growing majority of cases rather than all of them today. The right posture is to deploy IPv6 to every subscriber now (see the note on delivering IPv6), so that reachability improves automatically as the other end catches up.
A dedicated public IPv4: the universal answer
Assign the subscriber a routable public IPv4 and route around the CGN for them. Everything works, with every remote client, immediately. The cost is one address from a scarce pool, so this is the natural shape of a business tier or a paid "static IP" add-on rather than a default. It is the pragmatic choice whenever a customer needs guaranteed inbound today and cannot rely on the far end having IPv6.
PCP and operator static forwards: where they fit
Two mechanisms let an inbound mapping be created on a shared address:
- PCP (RFC 6887) lets the subscriber's device ask the CGN to open a specific inbound mapping, with a lifetime. It is the standards-based answer, but CPE support is patchy and it needs the CGN to implement it.
- Operator static port-forwards map a chosen public port on a shared address to one subscriber, configured by the ISP.
Netavo's CGN does not ship either today; both are on the roadmap rather than in the product. We call that out plainly so you plan around what exists: for inbound reachability on Netavo now, the tools are IPv6 and a dedicated public IPv4. PCP is worth watching as the long-term way to make shared-address inbound self-service, but it is not a reason to delay IPv6, which removes the need for it on most traffic.
Many devices do not need any of this
A large share of "I need inbound" cases are solved by the vendor, not the network. Most consumer CCTV, doorbells and IoT platforms connect out to the vendor's cloud and relay peer traffic through it, so they never need an inbound port at all. Before engineering reachability for a subscriber, check whether their device already uses a vendor relay. Often the answer is that nothing is required.
Choose by use case
| Use case | First choice | Why |
|---|---|---|
| Consumer CCTV / doorbell | Vendor relay (nothing to do) | The device already tunnels out to its cloud |
| Enthusiast home server | IPv6 | Routable per-device address, no IPv4 cost |
| Self-hosted game server | IPv6, else dedicated IPv4 | Many players are IPv6-capable; fall back for the rest |
| Business remote access / VPN | Dedicated public IPv4 | Guaranteed, works with every remote client today |
| Site-to-site between two of your subscribers | IPv6 | Both ends are yours and dual-stacked |
The strategic move is to ship IPv6 to every subscriber as standard and keep a small pool of public IPv4 for the business tier. That combination answers almost every inbound request without waiting for PCP, and it gets better on its own as IPv6 adoption rises at the far end.
Try the addressing model
The free evaluation build runs the production CGN alongside full dual-stack addressing, so you can test a subscriber on a shared IPv4 and a routable IPv6 prefix side by side and see which services each one reaches. Start at netavobng.com/evaluation; the addressing and CGN configuration is in the manual.