Carrier-grade NAT (CGNAT) is an ISP-side translation layer used to conserve public IPv4 addresses. RFC 6598 reserves 100.64.0.0/10 as shared address space for this purpose. A customer router can therefore receive a WAN address that is not publicly reachable even though browsing and outbound applications work normally. The provider translates many subscriber connections again before they reach a public IPv4 address.

The core idea

This matters most for inbound reachability. A port-forward rule on your home router controls only the NAT boundary you own. If the ISP performs another translation upstream, unsolicited connections from the internet usually cannot be mapped through that provider layer unless the ISP offers a specific service. Dynamic DNS also cannot create reachability by itself; it can name an address, but it cannot remove upstream NAT.

How to apply the idea

  • Compare the router WAN address with the public address reported externally.
  • If the WAN lies in 100.64.0.0/10, CGNAT is strongly indicated; private RFC 1918 WAN addresses can indicate an ISP gateway or provider NAT as well.
  • Confirm with the ISP before buying hardware or repeatedly changing port-forward rules.
  • For hosting, ask whether the provider offers a public IPv4, static IP, port mapping, IPv6, or business service.
  • Consider IPv6 when both endpoints/services support it and firewall policy is correctly configured.
  • For remote access, a VPN/overlay service that initiates outbound connections can work around lack of inbound IPv4 without exposing arbitrary ports.

What the evidence should tell you

Use these observations to connect the protocol concept to something measurable on a client, router, switch, packet capture, or status page.

  1. Compare the router WAN address with the public address reported externally. This observation reveals where the behavior occurs in the packet path.
  2. If the WAN lies in 100.64.0.0/10, CGNAT is strongly indicated; private RFC 1918 WAN addresses can indicate an ISP gateway or provider NAT as well. Use the result to distinguish protocol behavior from an unrelated application symptom.
  3. Confirm with the ISP before buying hardware or repeatedly changing port-forward rules. A contradictory result is a reason to revisit addressing, scope, or topology assumptions.
  4. For hosting, ask whether the provider offers a public IPv4, static IP, port mapping, IPv6, or business service. This observation reveals where the behavior occurs in the packet path.
  5. Consider IPv6 when both endpoints/services support it and firewall policy is correctly configured. Use the result to distinguish protocol behavior from an unrelated application symptom.
  6. For remote access, a VPN/overlay service that initiates outbound connections can work around lack of inbound IPv4 without exposing arbitrary ports. A contradictory result is a reason to revisit addressing, scope, or topology assumptions.

A concrete example

A router shows WAN 100.72.18.9 while an external site shows 198.51.100.x. Port 443 is forwarded correctly to a home server but remains unreachable from mobile data. The mismatch plus shared-address WAN strongly suggests provider NAT; the home router cannot create a mapping in a translation device it does not control.

Place the concept in the packet path

Networking terms become easier when you place them in a real packet path: client interface, local link, IP configuration, default gateway, translation or routing, provider network, DNS and the remote service. Ask which device makes the decision described by the term, what information it uses, and whether the behavior stays on the local link or crosses a router. That mental model prevents unrelated settings from being blamed for the same symptom.

Deeper technical context

CGNAT is conceptually similar to double NAT but occurs in the provider network. The shared-address block was created specifically so ISPs would not collide with ordinary RFC 1918 space when connecting customer equipment. Applications that are NAT-friendly often work transparently because the translation state is created by outbound traffic. Peer-to-peer hosting, some games, self-hosted servers, and inbound VPN endpoints are more likely to notice the difference.

Common mistakes that create bad conclusions

  • Forwarding the same port repeatedly on the home router when the ISP layer is the blocker.
  • Assuming a public-IP lookup and router WAN must always show the same number.
  • Treating CGNAT as a Wi-Fi problem.
  • Opening broad DMZ settings when the upstream provider still does not deliver unsolicited traffic.

Security and recovery notes

Use these steps only on networks and devices you own or are authorized to administer. Never weaken authentication, expose a management interface to the public internet, or publish router credentials merely to make troubleshooting easier. A normal reboot is very different from a factory reset: rebooting preserves configuration, while a reset can erase ISP, Wi-Fi, VPN, reservation, forwarding and segmentation settings. Prefer the least destructive test that can answer the question.

How to verify your conclusion

Do not stop at the first result that seems to confirm your theory. Repeat the decisive test after the change, compare it with a known-good client or path, and check that unrelated functions still work. For router changes, verify local management access, DHCP addressing, default gateway, DNS resolution, internet reachability and the specific feature you intended to fix. Keep the old setting in your notes until the network has remained stable long enough to trust the new state.

Why the distinction matters in real troubleshooting

Many networking mistakes come from solving the wrong layer: changing DNS for a DHCP failure, changing Wi-Fi channels for a WAN outage, opening a port when CGNAT blocks upstream reachability, or resetting a router because an ARP/VLAN problem prevents one client from reaching it. Place the symptom beside the protocol’s scope. If the concept cannot influence the failing path, it is probably not the root cause.

Questions people usually ask

Is 100.64.0.1 a private address?

It is not RFC 1918 private space; it belongs to the shared 100.64.0.0/10 block reserved for service-provider address sharing.

Can I port forward through CGNAT?

Usually not with only your home router. You need provider support, public addressing, IPv6, or an overlay/tunnel approach.

Does CGNAT slow the internet?

Not necessarily. Performance depends on provider implementation and many other factors. The defining issue is address sharing and inbound reachability.

Can a VPN help?

An outbound-initiated VPN or overlay can provide remote reachability, depending on the service and security model.

Standards and primary references

The explanation above is original editorial content. These references are linked for the underlying protocol or standards context, not as text to copy.

Bottom line

The useful outcome is not merely knowing the term or completing a setting change; it is being able to explain why the network behaved that way and reproduce the result safely. If the evidence points to a different layer than the one discussed here, follow the evidence rather than forcing the original theory.