How does CGNAT work?
CGNAT performs network address translation inside the service-provider network.
A typical home network already uses NAT:
Laptop / phone / TV
↓
Private IPv4 addresses
192.168.x.x
↓
Home router NAT
↓
Public IPv4 address
↓
Internet
The customer's router translates traffic from several private devices onto the public IPv4 address assigned to the connection.
With CGNAT, the service provider adds another translation layer:
Customer devices
↓
Home router
↓
Customer-side address
↓
ISP CGNAT
↓
Shared public IPv4 pool
↓
Internet
Many deployments therefore involve two translation domains: NAT inside the customer's network and CGNAT inside the provider's network.
The IETF defines a Carrier-Grade NAT as a NAT-based function used to share the same IPv4 address among several subscribers, with the CGN managed by the service provider rather than the subscribers. This definition and common operational requirements are documented in RFC 6888: Common Requirements for Carrier-Grade NATs.
CGNAT shares ports as well as addresses
CGNAT does not distinguish subscribers using the public IP address alone.
Transport-layer ports are also part of the translation.
A simplified example might look like this:
Subscriber A
100.64.10.20:50001
↓
203.0.113.20:22001
Subscriber B
100.64.20.30:51002
↓
203.0.113.20:22002
Subscriber C
100.64.30.40:52003
↓
203.0.113.20:22003
From an external service's perspective, all three subscribers can appear to connect from:
203.0.113.20
The CGNAT platform maintains translation state so returning traffic can be mapped to the correct subscriber and connection.
This address-and-port sharing is what allows a relatively small public IPv4 pool to serve a much larger number of users.
Why do ISPs use CGNAT?
ISPs primarily use CGNAT to reduce the amount of public IPv4 capacity required per subscriber.
Consider an access provider serving hundreds of thousands of residential customers. Giving every connection its own public IPv4 address consumes a correspondingly large pool.
CGNAT changes the allocation model from:
1 subscriber
=
1 public IPv4
to something closer to:
many subscribers
=
shared public IPv4 capacity
This makes CGNAT useful for broadband, mobile, wireless, and other large access networks where most customer traffic is outbound.
LARUS covers CGNAT alongside other address-management approaches in its guide to how ISPs manage IPv4 shortages.
The important distinction is simple:
CGNAT does not create new IPv4 addresses. It allows existing public IPv4 capacity to be shared more intensively.
What is the 100.64.0.0/10 CGNAT range?
The IPv4 prefix 100.64.0.0/10 is Shared Address Space reserved for service-provider networks, including CGN deployments.
The range extends from:
100.64.0.0
to
100.127.255.255
The IETF allocated this space in RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space. The document distinguishes Shared Address Space from RFC 1918 private address space because it is intended specifically for use within service-provider networks.
It is therefore different from familiar private ranges such as:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
100.64.0.0/10is also not ordinary globally routable public IPv4 space.
If a customer router receives a WAN address between100.64.0.0and100.127.255.255, that is one strong indication that CGNAT may be present.
It is not a universal detection method, however. Provider architectures differ, and not every shared-address deployment must look identical from the customer's side.
CGNAT vs NAT: what is the difference?
The main difference between ordinary customer NAT and CGNAT is where the translation occurs and who shares the public address.
Traditional NAT generally allows devices within one customer network to share
a public address controlled at the customer's router.
CGNAT adds translation at the service-provider level, allowing multiple
independent subscriber networks to share public IPv4 capacity.
|
Feature
|
Customer NAT
|
CGNAT
|
|
Operated by
|
Customer
|
ISP or service provider
|
|
Sharing scope
|
Devices inside one network
|
Multiple subscribers
|
|
Translation control
|
Customer often controls router
|
Provider controls CGN
|
|
Public IPv4 relationship
|
Usually associated with one customer connection
|
Shared among customers
|
|
Port forwarding
|
Often configurable
|
Usually more constrained
|
|
Attribution
|
Public IP often narrows activity to one customer connection
|
Public IP alone may represent many subscribers
|
|
Logging
|
Primarily local
|
Provider may need detailed subscriber/session correlation
|
For the underlying translation model, see LARUS's guide to Network Address Translation and how NAT works .
CGNAT is therefore not simply another name for home NAT. It moves large-scale
address sharing into the provider network.
Why does CGNAT make subscriber attribution harder?
A shared public IPv4 address can represent many subscribers at the same time.
That means a public IP address by itself may not identify which subscriber generated a particular connection.
Suppose an abuse report contains only:
Public IP: 203.0.113.20
Time: 14:35 UTC
If hundreds of subscribers were sharing that address at 14:35, the address alone may be insufficient for accurate attribution.
More useful information could include:
Public IP: 203.0.113.20
Source port: 22002
Timestamp: 14:35:27 UTC
Protocol: TCP
The service provider can then correlate that information against its subscriber assignments or CGN translation records.
RFC 6888 addresses CGN logging and notes the operational implications of recording enough information to identify the subscriber associated with a translated session.
This creates an important engineering trade-off:
CGNAT can reduce public IPv4 consumption while increasing the importance of accurate session mapping, timestamps, logging infrastructure, and abuse-response processes.
What are the limitations of CGNAT?
CGNAT works well for many ordinary outbound Internet applications.
Limitations become more visible when a workload depends on unsolicited inbound connectivity, predictable port behavior, or a distinct public source address.
The IETF's RFC 6269: Issues with IP Address Sharing describes several consequences of large-scale address sharing, including effects on inbound connections, applications that assume unique source addresses, monitoring, security, port allocation, and IP-based controls.
Inbound connectivity can become harder
A customer behind CGNAT generally does not control the provider's public-side translation.
That can complicate:
Applications and providers may support traversal mechanisms or alternative designs, but a CGNAT connection should not automatically be treated as equivalent to having directly usable public IPv4.
Port capacity becomes part of network planning
A public IPv4 address has a finite transport-port space.
When many subscribers share the same address, the CGN platform has to distribute ports and maintain translation state across them.
Operators therefore need to consider more than:
How many public IPv4 addresses are available?
They also need to consider:
How many simultaneous translations and usable ports can be supported at the intended sharing ratio?
Aggressive sharing may save address capacity while creating pressure elsewhere in the service architecture.
Shared addresses can create reputation spillover
External services often use source IP as one signal when applying:
-
Abuse controls
-
Fraud detection
-
Spam filtering
-
Rate limits
-
Security policies
-
Reputation scoring
With CGNAT, unrelated subscribers can share that signal.
If a shared public IPv4 address is blocked or develops a poor reputation, customers who had nothing to do with the triggering behavior may also encounter friction.
RFC 6269 discusses this kind of collateral impact as one consequence of large-scale IP address sharing.
CGNAT vs public IPv4: what actually changes?
The most useful comparison is not CGNAT versus no NAT.
It is whether the service requires shared outbound IPv4 access or direct public IPv4 capabilities.
|
Requirement
|
CGNAT
|
Public IPv4
|
|
General web browsing
|
Good fit
|
Good fit
|
|
Streaming
|
Usually good fit
|
Good fit
|
|
Conserve IPv4 capacity
|
Strong advantage
|
No sharing advantage
|
|
Distinct public source address
|
No
|
Yes
|
|
Customer-controlled inbound access
|
Restricted
|
Better fit
|
|
Port forwarding
|
Usually difficult
|
More controllable
|
|
Hosting public services
|
Often constrained
|
Better fit
|
|
IP allowlisting
|
Shared address can be problematic
|
Dedicated address is clearer
|
|
Subscriber attribution
|
Requires port/time correlation
|
Simpler at address level
|
|
Reputation isolation
|
Shared
|
Greater isolation
|
|
Public IPv4 use per subscriber
|
Low
|
Higher
|
The two architectures solve different problems.
CGNAT optimizes address utilization. Public IPv4 gives a network or customer
a more direct relationship with the address visible to the Internet.
The two architectures solve different problems.
CGNAT optimizes address utilization. Public IPv4 gives a network or customer a more direct relationship with the address visible to the Internet.
When is CGNAT a good fit?
CGNAT is well suited to services where subscribers mainly initiate outbound connections and do not require control of a public-facing IPv4 address.
Typical examples include:
For these customers, dedicating one public IPv4 address to every subscriber may provide little additional operational value relative to the amount of address capacity consumed.
CGNAT allows the operator to use public IPv4 more selectively.
When is public IPv4 a better fit?
Public IPv4 becomes more important when a workload depends on network capabilities that large-scale address sharing restricts.
Examples include:
-
Hosting public applications
-
Business VPN gateways
-
Enterprise firewall allowlisting
-
Remote-access infrastructure
-
Customer-controlled inbound services
-
Network appliances requiring predictable public addressing
-
Services sensitive to shared-IP reputation
-
Business connectivity requiring stable public egress addressing
A service provider does not need to choose one model for every customer.
A segmented design can look like this:
Residential / basic broadband
↓
CGNAT
Business connectivity
↓
Public IPv4 option
Hosting / infrastructure
↓
Routed public IPv4 capacity
CGNAT can then conserve address capacity where sharing fits the workload, while dedicated or routed public IPv4 remains available for services that need it.
CGNAT does not eliminate public IPv4 demand
A CGNAT architecture still requires public IPv4 on the Internet-facing side.
Operators may also need separate address capacity for business subscribers, hosting customers, public services, infrastructure products, or customers that require exceptions from the shared-address model.
As the network grows, capacity planning therefore becomes a combination of:
Traffic suitable for shared IPv4
+
Traffic requiring public IPv4
+
Capacity reserved for growth
This is why address sharing is only one part of the wider IPv4 scarcity and capacity-planning problem.
If business-IP products, hosting demand, public-address exceptions, subscriber growth, or CGN port pressure are increasing, the question becomes broader than how to configure NAT. It becomes a public IPv4 capacity decision.
Check LARUS IPv4 Availability & Continuity Assurance to evaluate additional production IPv4 capacity alongside an existing CGNAT architecture.
LARUS currently provides first-party IPv4 leasing from its own address pool and offers continuity controls covering areas such as routing validity, rDNS, RPKI/ROA readiness, reputation, abuse workflow, geolocation, support response, and renewal.
The operational cost of address sharing
CGNAT can reduce public IPv4 consumption, but it adds operational work elsewhere.
Depending on the network and requirements, operators may need to manage:
-
Translation infrastructure
-
Session capacity
-
Port allocation
-
Subscriber mapping
-
Time synchronization
-
Log generation and storage
-
Abuse investigations
-
Shared-address reputation
-
Customer exceptions
-
Dedicated public-IP service tiers
BTW.Media examines the logging side of this problem in its analysis of CGNAT logging mandates and IPv4 scarcity costs, including the infrastructure needed for translation records, time accuracy, storage, and subscriber attribution.
For operators, that leads to a workload-specific design choice: use shared addressing where it meets customer requirements, and retain public IPv4 capacity where direct reachability, distinct source addressing, reputation isolation, or greater control matters.
FAQ
Is 100.64.0.0/10 a public IP range?
No.100.64.0.0/10is Shared Address Space reserved for service-provider use. RFC 6598 defines the range for scenarios including Carrier-Grade NAT and distinguishes it from ordinary public IPv4 space.
How can I tell if I am behind CGNAT?
Compare the WAN IPv4 address shown by your router with the public IPv4 address seen by an Internet service. If they differ—and especially if the router has an address within100.64.0.0/10—CGNAT may be present. Provider architectures vary, so your ISP can give the definitive answer.
Does CGNAT prevent port forwarding?
CGNAT usually makes ordinary customer-controlled inbound port forwarding more difficult because the customer does not control the provider's external translation layer. Some providers or applications support alternative mechanisms, so the exact behavior depends on the deployment. RFC 6269 discusses the challenges that address sharing creates for inbound ports and connections.
Is CGNAT bad for gaming, VPNs, or peer-to-peer applications?
Not universally. Many applications work normally, while applications that rely on inbound sessions, direct peer connectivity, particular NAT behavior, or predictable port mappings can experience limitations. The result depends on the application and the provider's CGN implementation.
Does CGNAT solve IPv4 exhaustion?
CGNAT reduces the number of public IPv4 addresses required per subscriber by sharing addresses, but it does not create new public IPv4 space. Providers still require public IPv4 for the Internet-facing side of the CGN and for services that need direct public addressing.
Sell IPv4 Addresses
Network Partners
Blog
Insights
Knowledge Base
Support Center
Mini Speaker
Log In
