Carrier-Grade NAT (CGNAT) Explained: How Shared IPv4 Works

Quick Answer

Carrier-Grade NAT, or CGNAT, is a provider-operated form of network address translation that allows multiple subscriber connections to share public IPv4 resources.

Instead of assigning one public IPv4 address exclusively to each subscriber connection, an ISP can translate traffic from several subscriber contexts through a smaller set of public addresses. Source ports and translation state help the system distinguish simultaneous connections that appear on the Internet under the same public IP.

A simplified model is:

Device → [Optional Home Router / CPE NAT] → Subscriber Context → ISP CGN → Shared Public IPv4 + Translated Source Port → Internet

This is a conceptual vendor-neutral model. Home NAT is optional, double NAT does not exist for every CGN subscriber, and real ISP implementations can use different addressing, translation and transition architectures.

The central distinction is:

One Public IPv4 → Potentially Multiple Subscriber Connections

Therefore:

Public IPv4 ≠ Subscriber

Public IPv4 ≠ Household

Public IPv4 ≠ Device

CGNAT ≠ Proxy

Key Takeaways

• CGNAT is a provider-managed NAT function used to share IPv4 resources across multiple subscriber connections.
• NAT is the broader translation concept. It is not limited to home routers.
• Home NAT can share one subscriber connection among local devices, while CGNAT can share public IPv4 resources among subscribers.
• Home NAT and CGNAT can create two translation layers, but this is not universal.
• 100.64.0.0/10 is Shared Address Space for service-provider use. It is neither ordinary RFC 1918 private space nor public Internet address space.
• Source ports and protocol information help CGN distinguish concurrent flows using the same public IPv4.
• Port forwarding on a home router may not control the separate translation layer operated by the ISP.
• A public IPv4 alone may be insufficient to identify one subscriber when the address is shared.
• WAN-address checks can provide evidence of CGN, but no single consumer test detects every implementation with certainty.
• CGN does not guarantee anonymity, replace a firewall or turn a connection into a proxy.

What Is Carrier-Grade NAT?

Carrier-Grade NAT is a NAT-based logical function operated within a service-provider network. It allows the same public IPv4 address to be shared among several subscribers.

RFC 6888 uses Carrier-Grade NAT, or CGN, for this provider-managed function. It also explains that carrier-grade is a topological description, not a guarantee of quality. The important distinction is where the translation occurs and who controls it.

A subscriber normally has limited or no control over the provider’s CGN. This differs from a NAT function inside a customer-controlled home or office router.

CGNAT is also called Large-Scale NAT, or LSN, in some technical and commercial contexts. The exact architecture behind these terms can differ.

A Conceptual CGNAT Path

A basic outbound path may look like this:

Device

↓

Optional Customer-Premises NAT

↓

Subscriber Address or Connection Context

↓

ISP CGN

↓

Shared Public IPv4 and Translated Port

↓

Internet Destination

The destination sees the translated public source address. It does not automatically see the original local device address or the subscriber-side address used before the provider translation.

The model does not require every subscriber to use a home router. A mobile connection, public access network or another provider design may reach the CGN without a separate customer-controlled NAT layer.

What Is the Difference Between NAT and CGNAT?

NAT is a general translation function. CGNAT is one provider-scale use of NAT.

The safest simplified comparison is:

Home NAT:

Multiple Local Devices → One Subscriber Connection or Public Context

CGNAT:

Multiple Subscriber Connections → Shared Public IPv4 Resources

Dimension	NAT in general	Carrier-Grade NAT
Main meaning	Translation between address contexts	Provider-managed NAT serving multiple subscribers
Possible location	Home, office, datacenter, enterprise edge or provider network	Logically inside a service-provider architecture
Sharing boundary	Depends on the deployment	Public IPv4 resources can be shared across subscribers
Operator	The user, organization, host or network provider	The service provider or its infrastructure operator
Subscriber control	Depends on the deployment	Usually limited or unavailable
Scale	Not defined by one universal size	Intended for multi-subscriber operation
Mapping behavior	Implementation-dependent	Also implementation-dependent, with additional provider-scale requirements

It would be inaccurate to reduce this to NAT = home and CGNAT = ISP. NAT exists in many network environments.

The stronger distinction is:

CGNAT moves the IPv4-sharing boundary into the service-provider network and allows the public side of that translation to be shared across subscriber contexts.

When Double NAT Exists

A common residential arrangement contains both:

1. a NAT function on the home router;
2. a separate CGN function inside the ISP.

This can produce a path such as:

Private Device Address → Home Router Translation → Subscriber-Side Address → ISP Translation → Public IPv4

That is sometimes described as double NAT. In a traditional IPv4 example with three address realms, the term NAT444 may also appear.

However, a second customer-controlled NAT is not required for something to qualify as CGN. RFC 6888 includes a hotspot example in which a CGN serves customers without a second NAT layer at customer premises.

Private, Shared and Public IPv4 Address Space

Understanding CGNAT requires separating three address categories.

Address category	Example	Intended context	Globally routable on the public Internet?
RFC 1918 private IPv4	10.0.0.0/8	Private networks	No
RFC 1918 private IPv4	172.16.0.0/12	Private networks	No
RFC 1918 private IPv4	192.168.0.0/16	Private networks	No
RFC 6598 Shared Address Space	100.64.0.0/10	Service-provider shared-address contexts	No
Public IPv4	Provider- or registry-managed public space	Public Internet connectivity	Potentially, when properly routed

RFC 1918 Private Space

RFC 1918 reserves three blocks for private internets:

• 10.0.0.0/8;
• 172.16.0.0/12;
• 192.168.0.0/16.

These addresses can be reused by unrelated private networks because they do not have globally unique meaning.

A home router commonly assigns addresses from one of these ranges to local devices. This does not, by itself, say anything about whether the ISP uses CGN.

RFC 6598 Shared Address Space

RFC 6598 designates 100.64.0.0/10 as Shared Address Space.

Its range is:

100.64.0.0 – 100.127.255.255

Shared Address Space resembles private space in that it is not intended to be routed across the public Internet. However, it is not an additional RFC 1918 block. It was designated for service-provider use, including addressing between customer-premises equipment and CGN functions.

The distinction should remain explicit:

100.64.0.0/10 is Shared Address Space, not ordinary RFC 1918 private space and not public Internet address space.

An address from this range on a router’s WAN interface is strong evidence of a provider shared-address context.

It is not a universal requirement for every CGN deployment. Providers can use different architectures, other internal address contexts, encapsulation or transition mechanisms. Therefore, not seeing 100.64.0.0/10 does not prove that CGN is absent.

Public IPv4

A public IPv4 address is not reserved for RFC 1918 private use or RFC 6598 Shared Address Space. It can participate in public Internet routing when the relevant prefix is announced and operationally reachable.

Under CGN, this is normally the source address an external website or server observes after translation. Several subscribers may appear under that address at the same time.

How CGNAT Works

CGNAT translates subscriber-side traffic into a public IPv4 and maintains enough state to direct response traffic correctly.

A simplified mapping is:

Subscriber Address + Source Port + Protocol

↓

CGN Mapping

↓

Shared Public IPv4 + Translated Source Port + Protocol

Suppose two subscriber connections independently create outbound TCP flows. They may both be translated to the same public IPv4, but the CGN can assign or preserve different public-side source ports.

The external observations might conceptually look like:

Subscriber A → Shared Public IPv4 : Port A

Subscriber B → Shared Public IPv4 : Port B

Subscriber C → Shared Public IPv4 : Port C

The public IP is shared, while the translated port and protocol help distinguish the mappings.

Why Ports Matter

An IPv4 address alone cannot distinguish every concurrent connection using that address. TCP and UDP ports add another identifier.

RFC 3022 describes Network Address Port Translation, or NAPT, as translating multiple internal addresses and their TCP or UDP ports into one external address and its ports.

In practice, a translation system can consider several fields associated with a flow. The exact mapping and filtering behavior depends on the implementation. RFC 4787 defines NAT mapping and filtering terminology for UDP, but it should not be interpreted as evidence that every deployed NAT behaves identically.

The article therefore should not assume:

• a fixed port range for every subscriber;
• a universal port-allocation algorithm;
• one mapping lifetime;
• one subscriber-to-public-IP ratio;
• the same behavior for every protocol.

Translation State

The CGN maintains operational state connecting subscriber-side traffic to its public-side representation. When response packets arrive, that state helps the system determine where they should be sent.

Mappings can be created, reused and removed according to provider and implementation rules. They are not permanent ownership relationships between one subscriber and one public IP.

Recommended future visual placement: after this section. Show Several Subscriber Connections → ISP CGN → One Shared Public IPv4 + Different Port Mappings. Label it Conceptual vendor-neutral model; implementations vary.

Why Do ISPs Use CGNAT?

One major reason is limited public IPv4 availability.

Without address sharing, an ISP providing conventional public IPv4 connectivity would need enough public addresses for its active subscriber addressing model. CGN lets public IPv4 resources be shared across multiple connections instead.

This can help a provider:

• continue offering IPv4 connectivity while public address resources are limited;
• serve more subscriber connections from an available public IPv4 pool;
• support existing IPv4-only destinations during the transition toward broader IPv6 deployment;
• implement its chosen access-network and transition architecture.

IPv4 scarcity is a major motivation, but it is not the only possible architectural consideration. RFC 6888 notes that some providers used this type of service even before acute IPv4 shortage.

No universal sharing ratio exists. The number of subscribers, connections or ports associated with one public address can depend on:

• the provider’s design;
• subscriber traffic;
• available address resources;
• port-management policy;
• capacity and state limits;
• protocol behavior;
• time and current network conditions.

A headline such as “one IP is shared by a specific number of users” should not be generalized without evidence from the particular implementation.

Port Forwarding and Inbound Connectivity

CGNAT can make unsolicited inbound IPv4 connectivity more difficult because the public mapping is controlled upstream of the subscriber’s own network.

What Home-Router Port Forwarding Controls

A port-forwarding rule on a home router controls the translation or filtering behavior of that router.

For example:

Home Router External Port → Local Device and Port

That can be sufficient when the router itself has a publicly reachable IPv4 and the ISP permits the inbound traffic.

Under CGN, however, the router may only have a subscriber-side address. The public IPv4 seen by the Internet belongs to a separate provider-controlled translation context.

The full path then becomes:

Internet

↓

Provider-Controlled Public Mapping

↓

Subscriber-Side Address

↓

Home-Router Port Forwarding

↓

Local Device

Configuring the final home-router layer does not automatically create the required upstream CGN mapping.

Why Unsolicited Inbound Traffic Is Harder

For an outbound flow, the CGN can create translation state when the subscriber initiates communication.

An unsolicited inbound packet presents a different problem. The provider translator needs enough information and an appropriate mapping or control mechanism to know which subscriber should receive it.

A public IPv4 alone may correspond to several subscriber connections. A destination port might also be unavailable or assigned under provider-specific rules.

This can affect:

• self-hosted services;
• direct remote access;
• some peer-to-peer applications;
• some gaming scenarios;
• inbound VPN hosting;
• applications that expect external peers to initiate connections.

It does not mean every affected application always fails. Provider offerings and translation behavior vary. An ISP might offer another access model, explicit mapping mechanism, public IPv4 option or IPv6 connectivity.

Those alternatives are provider-specific. This article does not provide NAT traversal or bypass instructions.

How to Tell if You Are Behind CGNAT

No single consumer heuristic detects every implementation with complete certainty. The most useful approach combines several observations.

Step 1: Find the Router’s WAN IPv4 Address

Open the status or Internet-connection page of the router or CPE and locate its IPv4 WAN address.

The label may vary:

• WAN IP;
• Internet IP;
• IPv4 address;
• external interface address;
• broadband address.

Make sure you are looking at the Internet-facing interface, not the router’s LAN address.

In a network with a separate modem, mesh gateway or nested router, the displayed WAN address may belong to another customer-controlled layer rather than directly to the ISP connection.

Step 2: Check the Public IPv4 Seen Externally

Use What Is My IP to see the address observed from your current Internet request.

For a clean comparison:

• check the IPv4 result;
• temporarily account for any active VPN;
• account for any proxy configured in the browser or operating system;
• use the same connection whose router WAN address you inspected.

The tool shows the public address visible to its server. It does not inspect the ISP’s internal NAT architecture and should not be described as a CGNAT detector.

Step 3: Classify the WAN Address

Check whether the router’s WAN IPv4 belongs to one of these categories:

WAN address	What it suggests
100.64.0.0/10	Strong evidence of service-provider Shared Address Space
RFC 1918 range	An upstream private-address or nested-NAT context exists
Public IPv4	The WAN interface has public address space, subject to actual routing and architecture

An RFC 1918 WAN address can be caused by CGN, but it can also result from another router or private upstream network. It is not specific proof of CGN.

Step 4: Compare the WAN and External IPv4 Addresses

If the router reports one IPv4 and an external service observes another, some additional translation, tunneling or intermediary function may exist.

Possible explanations include:

• provider NAT or CGN;
• a second customer-controlled router;
• a VPN;
• a proxy;
• multi-WAN routing;
• a modem management interface;
• another ISP transition architecture.

Therefore:

WAN / External IP Mismatch = Evidence of an Additional Network Layer

It does not automatically mean:

WAN / External IP Mismatch = Proven CGNAT

If the public WAN IPv4 matches the external result, there is no obvious IPv4 translation between those two observation points. That result still does not describe every middlebox or provider mechanism on the path.

Step 5: Use Other Symptoms Only as Supporting Evidence

Failed port forwarding, private hops in a traceroute or application messages about restrictive NAT can support further investigation.

They are not conclusive by themselves. Similar symptoms can result from:

• router firewalls;
• nested home networks;
• incorrect forwarding rules;
• application configuration;
• provider filtering;
• routing problems;
• device firewalls;
• protocol-specific NAT behavior.

Step 6: Ask the ISP

The strongest practical confirmation is the provider’s answer about the service.

Useful questions include:

• Does this plan use CGN or shared public IPv4?
• Is the WAN address expected to come from Shared Address Space?
• Does the service offer a public IPv4 option?
• Is inbound IPv4 connectivity supported?

The answers apply to that provider and service. They should not be generalized to other ISPs.

What CGNAT Can Change in Practice

CGNAT does not make ordinary outbound Internet access inherently unusable. Many common applications begin with an outbound connection, allowing the translation system to create the necessary state.

The differences become more visible when an application depends on direct inbound reachability or assumes that one public IP represents one user.

Area	Possible CGNAT implication
Normal web browsing	Often works through outbound mappings
Self-hosting	Public inbound mapping may not be under subscriber control
Remote access	Direct inbound IPv4 access may require provider support or another architecture
Gaming	Some peer-hosting or direct-connect behavior may be affected
Peer-to-peer traffic	Incoming peer connectivity may be limited
VPN use	Connecting outward to a VPN differs from hosting an inbound VPN service
IP-based rate limits	Several subscribers can appear under one public IPv4
IP allowlists	A shared or changing public IP may be unsuitable as a unique subscriber credential
Geolocation	Public egress metadata may describe the provider’s egress context rather than one precise device location
Abuse handling	Public IPv4 alone may not distinguish the responsible subscriber

These are possible architectural effects, not guarantees about every application or provider.

Logging and IP-Level Attribution

When several subscribers share one public IPv4, that address alone may be insufficient to distinguish them.

A simplified correlation can involve:

Public IPv4 + Source Port + Protocol + Accurate Timestamp

↓

Provider Mapping Records

↓

Relevant Subscriber Context

RFC 6888 discusses mapping information such as the subscriber identifier, external source address, external source port, transport protocol and timestamp.

RFC 6302 recommends that Internet-facing servers which log incoming IP addresses also log source ports and accurate timestamps. Protocol and destination-port information may also be relevant depending on the service.

Timing matters because mappings and ports can change. The same public IP and port may not represent the same subscriber context indefinitely.

The safe conclusion is:

Public IPv4 alone may be insufficient for subscriber-level attribution under address sharing.

It would be inaccurate to conclude that attribution is always impossible. Whether correlation succeeds depends on the information recorded, its accuracy and the relevant implementation.

This is a technical explanation only. Retention periods, disclosure obligations and access to records depend on applicable policies and law and are outside this article’s scope.

Does CGNAT Affect Performance?

CGN maintains translation state and uses finite address, port, processing and memory resources.

RFC 6888 discusses per-subscriber port and state limits as well as situations where a CGN cannot create a new mapping because of resource constraints or administrative restrictions.

This supports a limited conclusion:

CGN performance and capacity depend on the implementation, configuration, available resources and workload.

It does not support the universal claims that CGNAT:

• is always slower;
• always increases latency;
• inherently causes packet loss;
• assigns a fixed number of ports to every subscriber;
• uses one standard subscriber-to-IP ratio.

A well-provisioned implementation and an overloaded or misconfigured implementation can produce very different outcomes. Connection problems should be diagnosed rather than attributed to CGN solely because it is present.

How CGNAT Relates to IPv6

CGNAT extends the operational usefulness of limited IPv4 resources by allowing public addresses to be shared.

IPv6 provides a much larger address space. As more traffic works over native end-to-end IPv6, providers can reduce the amount of traffic that depends on shared public IPv4.

RFC 6269 identifies increased IPv6 deployment as the long-term way to reduce pressure on the public IPv4 pool and the burden placed on address-sharing systems.

CGNAT and IPv6 are not interchangeable:

• CGN shares IPv4 resources;
• native IPv6 uses IPv6 addressing;
• dual-stack networks can support both protocols;
• transition architectures may combine IPv4 and IPv6 components.

IPv6 also does not automatically eliminate firewalls, transition mechanisms, operational restrictions or every possible form of address translation.

What CGNAT Does Not Guarantee

CGNAT Is Not Automatically a Firewall

NAT mapping and packet-filtering behavior are related but separate concepts. RFC 4787 distinguishes mapping behavior from filtering behavior.

Reduced unsolicited inbound reachability can have an operational side effect that resembles filtering. It does not replace endpoint security, firewall policy, updates, authentication or application-level controls.

CGNAT Does Not Guarantee Anonymity

A destination may see a shared public IP, but it can also observe:

• account information;
• cookies;
• browser or device characteristics;
• request behavior;
• authentication data;
• application identifiers;
• timing and session patterns.

The ISP can also maintain internal information connecting translations to subscriber contexts.

Shared addressing therefore does not mean that a subscriber is anonymous or cannot be distinguished through other evidence.

CGNAT Does Not Make Attribution Impossible

The public IP alone may be insufficient, but ports, protocol, timestamps and mapping records can provide additional correlation data.

The correct conclusion is IP-only attribution may be ambiguous, not attribution is impossible.

CGNAT Does Not Create a Proxy

A CGN translates traffic for subscribers as part of a provider network. A proxy accepts and forwards traffic according to a separate service or application-layer relationship.

The presence of CGN does not establish that:

• the subscriber is operating a proxy;
• another customer can select that subscriber as an exit;
• the connection belongs to a proxy pool;
• the ISP offers a proxy service.

Why CGNAT Matters When Interpreting Residential IPs

A residential public IPv4 observed by a destination does not necessarily identify one subscriber, household or device.

One household can contain many devices behind a home router. Separately, CGN can allow several subscriber connections to share one public IPv4.

The resulting relationships are not one-to-one:

Public IPv4 ≠ Subscriber

Public IPv4 ≠ Household

Public IPv4 ≠ Device

Public IPv4 ≠ Proxy Peer

For the broader distinction between residential connectivity, subscribers, devices, participants and proxy-capable supply, see Residential Proxy Supply Chain Explained.

Residential classification also does not prove that CGN is present. A residential address may be used in a connection with a dedicated, dynamic or shared public context. The exact topology requires separate evidence.

Shared Addressing and IP History

A shared public IPv4 can aggregate externally observed traffic from multiple subscriber contexts. This can complicate assumptions based only on IP history.

It does not follow that every CGN address has poor reputation or that CGN improves reputation. Target websites can use their own data, time windows, rules and additional signals.

The deeper distinction between address identity, historical behavior and target-side treatment belongs to How IP Reputation Works.

Practical Examples

Example 1: Home NAT and CGN Form Two Translation Layers

A laptop has an RFC 1918 address assigned by a home router. The router’s WAN interface receives an address from 100.64.0.0/10. An external website sees a public IPv4 that is different from the WAN address.

The conceptual path is:

Laptop Private IPv4

↓

Home Router NAT

↓

RFC 6598 Shared Address

↓

ISP CGN

↓

Public IPv4

In this example, two translation layers exist. A forwarding rule on the home router controls only the first layer. It does not automatically create a public mapping on the ISP CGN.

Example 2: CGN Exists Without a Home NAT

A subscriber connects through an access network that does not place a customer-controlled NAT router in the IPv4 path. The provider still translates traffic from multiple subscriber contexts through shared public IPv4 resources.

The path is:

Subscriber Context

↓

ISP CGN

↓

Shared Public IPv4

This remains CGN even without a second home NAT layer.

The example shows why CGNAT and double NAT are not synonyms.

Example 3: One Public IP Is Not Enough for Attribution

Two subscribers create connections that leave through the same public IPv4 during the same period. Their translated source ports differ.

A server log containing only the public IP cannot necessarily distinguish them. A record containing the public IP, source port, protocol and accurate timestamp can provide the information needed for correlation with the provider’s mapping records.

This does not guarantee that the necessary records exist or can be accessed. It demonstrates why the public address alone is incomplete.

Check the Network Layer Before Blaming the Application

If inbound access or port forwarding stops working, first identify the addressing path.

Compare the router’s WAN IPv4 with the public IPv4 visible externally, classify the WAN address correctly and account for VPNs, proxies or nested routers. If the evidence points to provider-side translation, confirm the service architecture with the ISP.

This produces a more reliable diagnosis than assuming every private WAN address, failed port test or hidden traceroute hop proves CGNAT.

Final Thoughts

CGNAT is best understood as provider-scale IPv4 address sharing.

Its defining feature is not simply the presence of a private address or a second router. The essential relationship is that multiple subscriber connections can use shared public IPv4 resources through provider-controlled translation.

That changes the meaning of an observed public IP. The address identifies a public egress context, but it does not necessarily identify one subscriber, household or device.

CGN also creates practical boundaries. A subscriber may control the home router without controlling the public mapping. A port-forwarding rule can be correct locally while an upstream translation layer still prevents unsolicited inbound traffic from reaching it.

The most reliable approach is to separate each layer:

Local Device → Optional Home NAT → Subscriber Context → ISP CGN → Public Egress

Once those layers are distinguished, addressing, diagnostics, inbound connectivity and IP-level attribution become much easier to interpret accurately.

Glossary

Carrier-Grade NAT / CGN / CGNAT
A provider-managed NAT logical function that allows public IPv4 resources to be shared across multiple subscriber contexts.

Large-Scale NAT / LSN
Related terminology for provider-scale address translation. Exact implementations and usage can vary.

NAT
Network Address Translation. A broader function that maps addresses between network contexts.

NAPT / PAT
Address and port translation that enables multiple internal connections to share external addressing through different transport-port mappings.

CPE
Customer-premises equipment, such as a residential router or gateway.

Subscriber
A provider-side customer, account or service context. It is not necessarily one person, household or device.

RFC 1918 Private Address Space
The reusable private IPv4 blocks 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16.

Shared Address Space
The 100.64.0.0/10 block designated by RFC 6598 for service-provider use in shared-address contexts.

Public IPv4
IPv4 address space that can participate in public Internet routing when properly announced and operationally reachable.

Public Egress IP
The public source address observed by an Internet destination after any relevant translation.

Source Port
A transport-layer identifier used by TCP or UDP. Translated source ports help distinguish flows sharing a public IPv4.

Flow
A network communication instance described through protocol, address and port information.

Mapping
The translation state connecting a subscriber-side flow with its public-side address and port representation.

Double NAT
A path containing two separate NAT layers. Home NAT plus provider CGN is one possible example, but not every CGN subscriber has this topology.

Port Forwarding
A rule that directs inbound traffic arriving at a selected address and port toward an internal destination. A home-router rule does not automatically control an upstream ISP translation.

IP-Level Attribution
An attempt to connect observed Internet activity to a network or subscriber context using address and supporting data such as ports, protocol, time and mapping records.

Frequently asked questions

Here we answered the most frequently asked questions.

Ask a question

What is CGNAT?

CGNAT is a provider-managed NAT function that lets multiple subscriber connections share public IPv4 resources. It translates subscriber-side traffic into public IPv4 addresses and maintains mappings that help return traffic reach the correct subscriber context.

What is the difference between NAT and CGNAT?

NAT is the general address-translation concept and can be deployed in many environments. CGNAT is a provider-operated form of NAT used across multiple subscribers. Home NAT commonly shares one connection among local devices, while CGN can share public IPv4 resources among subscriber connections.

Is CGNAT the same as double NAT?

No. Home NAT plus provider CGN creates two translation layers, but a CGN deployment can exist without customer-controlled home NAT. Double NAT describes the number of translation layers, while CGN describes a provider-managed multi-subscriber NAT function.

Is 100.64.0.0/10 a private IP range?

It is non-public Shared Address Space designated by RFC 6598 for service-provider use. It is not one of the ordinary RFC 1918 private ranges and is not public Internet address space.

Does every CGNAT connection use 100.64.0.0/10?

No. The range is specifically designated for service-provider shared-address contexts, but real CGN and transition implementations can use different architectures. Its absence does not prove that CGN is absent.

How can I tell if my connection is behind CGNAT?

Compare the router’s IPv4 WAN address with the public IPv4 observed externally. A WAN address in 100.64.0.0/10 is strong evidence. An RFC 1918 WAN address or WAN-to-public mismatch indicates another network layer may exist, but does not prove CGN by itself. Ask the ISP for confirmation.

Why does port forwarding often fail under CGNAT?

A home-router forwarding rule controls only the home router. Under CGN, the public IPv4 mapping is managed by an upstream provider translator. Inbound traffic also needs an appropriate mapping or control mechanism at that layer.

Can I use a VPN when I am behind CGNAT?

Outbound connections to a VPN service can often work because they create translation state. Hosting a VPN endpoint that must accept unsolicited inbound IPv4 connections is a different requirement and may be affected by the upstream CGN.

Does CGNAT always make Internet connections slower?

No. Performance depends on the implementation, capacity, configuration and workload. CGN consumes translation and port resources, but its presence alone does not prove higher latency, lower throughput or packet loss.

Does CGNAT provide security like a firewall?

No. Translation and filtering are separate concepts. Reduced unsolicited inbound reachability can have a protective operational effect, but CGN does not replace a firewall, endpoint security, authentication or software updates.

Does CGNAT make users anonymous?

No. Shared public addressing does not hide account data, cookies, device characteristics, behavior or other identifiers. Provider mapping records may also connect translated traffic to a subscriber context.

Can a public IPv4 identify one subscriber behind CGNAT?

Not necessarily. Correlation may require the public IP, source port, protocol, accurate timestamp and provider mapping records. The public IPv4 alone can be ambiguous when several subscribers share it.

Does CGNAT create a proxy?

No. CGN performs provider-side address translation. It does not automatically provide a proxy service, allow customers to select subscriber connections as exits or make the translated connection part of a proxy pool.

Do residential proxies necessarily use CGNAT?

No. Residential classification does not reveal the complete access-network topology. A residential public IP can come from a dedicated, dynamic or shared public context. Provider-specific evidence is required.

Is IPv6 a replacement for CGNAT?

Broader native IPv6 deployment can reduce dependence on shared public IPv4, but networks may still support IPv4, IPv6 and transition mechanisms together. IPv6 does not automatically eliminate firewalls, operational restrictions or every translation mechanism.