MyIP.dogCheck for CGNAT using the correct two observations
Compare the WAN or Internet IPv4 address shown by your router with the public IPv4 source seen by a website on the same connection. A WAN value in 100.64.0.0/10 is a strong clue that shared carrier addressing is involved. A mismatch needs further context: a second local router, VPN, proxy or different connection can also explain it. A public-IP website cannot conclusively detect every CGNAT deployment from one request.
CGNAT means carrier-grade network address translation. It allows a provider to share public IPv4 resources across customers by maintaining translation state upstream of their equipment. Your own home router may perform another translation layer. Understanding those separate layers is essential before deciding whether an incoming connection problem can be fixed in your router or requires help from the provider.
Compare WAN and public IPv4
First, connect through the household network you want to investigate. Record the public IPv4 observation and time using the IPv6 test, which includes a separate IPv4 endpoint check. A general homepage result may use IPv6, so verify the family before comparing it with an IPv4 WAN field. Keep VPN and proxy routing in mind and use an authorized baseline appropriate to your network.
Next, open your router's administration interface or provider app and locate Internet status, WAN status or the equivalent field. The router address guide helps you find the local management path. Do not use the router's LAN gateway address for this CGNAT comparison. A local gateway such as 192.168.1.1 is expected on many home networks and says nothing by itself about the provider's public assignment.
Record both values privately with the observation time. If you cannot inspect the WAN status, ask the provider whether your service receives a dedicated public IPv4 address or uses CGNAT. Browser scripts do not automatically know your router's WAN configuration. A site claiming certainty without that evidence may be guessing from patterns rather than confirming your service architecture.
Identify shared address space
The designated shared IPv4 space is 100.64.0.0/10, spanning 100.64.0.0 through 100.127.255.255. RFC 6598 defines this range for shared address space associated with carrier-grade NAT. It is distinct from the private-use ranges in RFC 1918. Not every address beginning with 100 belongs to it, so check the complete range rather than only the first number.
A WAN assignment in that shared range supports a CGNAT hypothesis, but context still matters. Networks can use addressing in specialized ways, and configuration errors can exist. Treat the range as evidence to confirm with the operator, especially when an important service depends on incoming access. Do not label another subscriber or network as misconfigured merely from a screenshot of one address field.
Interpret the comparison carefully
If the router's WAN IPv4 matches the website's public IPv4 and the requests used that router without a different exit, the observations do not show an extra address-translating layer for that path. This is useful evidence, but it does not guarantee that every inbound port is available. Firewalls, provider filtering and the listening application remain separate parts of a connection.
If the WAN value is in the shared range and differs from the public source, ask the provider to confirm CGNAT and its supported options. If the WAN value is in a private range such as 10.0.0.0/8, investigate upstream routing as well. A private WAN can indicate another router in your premises, a building network or a provider arrangement. It does not uniquely identify CGNAT.
If both values are public but differ, first verify that you compared the same family, time and traffic path. A browser VPN, proxy or another active connection can produce the mismatch. Avoid changing port-forwarding settings until the CGNAT comparison itself is sound. Otherwise you may spend time adjusting a router that is not carrying the test traffic.
Distinguish carrier translation from double NAT
Double NAT describes two translation layers on the path; CGNAT describes a provider-scale arrangement that can be one of those layers. A provider gateway in router mode connected to your own router can create double NAT inside the customer setup. That is a different administrative situation from an upstream translation service you cannot configure yourself.
Map the equipment you actually control. A modem, optical terminal, router and Wi-Fi access point do not necessarily perform the same jobs. Ask the provider which device terminates the service and which mode is supported before changing bridge settings. A CGNAT diagnosis should explain where control stops, rather than treating every box or private address as the same problem.
Why an ordinary router rule can fail
A port-forwarding rule on your home router controls that router's translation and firewall behavior. It does not automatically create a matching rule in a provider's CGNAT gateway. An unsolicited incoming IPv4 connection may therefore never reach your router, even when the local forwarding rule looks correct. RFC 6888 describes carrier-grade NAT requirements and operational concerns.
A failed connection still does not prove CGNAT on its own. The target service might not be listening, the local firewall might reject traffic, the forwarding target might have changed or the test might use the wrong protocol. Preserve the address comparison and the actual symptom. Diagnose these layers independently instead of treating a single closed-port result as a complete explanation.
Options for remote access
Ask the provider whether a public IPv4 option is available and whether it is dynamic or static. Those are different properties: a public address can still change. Explain the application you need to support and confirm any incoming-port restrictions. A CGNAT opt-out or different service arrangement depends on the provider; it should not be presented as a universal free setting available to every customer.
IPv6 may offer another path when the application and both endpoints support it and the firewall is configured appropriately. CGNAT is an IPv4 translation issue, so IPv6 needs its own evaluation. A globally scoped IPv6 assignment does not automatically expose every local service, and IPv4-only clients cannot directly use an IPv6-only destination without an appropriate intermediary.
A managed remote-access service or an outbound tunnel can also fit some needs. Evaluate the actual application, authentication and provider terms. Merely enabling a consumer VPN does not guarantee incoming port support or remove every CGNAT-related constraint. Likewise, dynamic DNS updates a name but does not by itself create a route through an upstream translator.
What the comparison does not establish
CGNAT does not mean that every customer has the same local address, that the connection is anonymous or that the provider can never distinguish sessions. It also does not make address-based reputation a reliable judgment of each subscriber. Many people can share a public source, so problems affecting that source need to be interpreted with that sharing in mind.
The public address alone cannot identify which household generated a particular event. An investigation would need additional records and context beyond an ordinary lookup. Similarly, CGNAT is not a replacement for device updates, application authentication or firewall policy. Keep routing limitations separate from claims about identity and security.
Prepare a useful provider support request
Send the provider the relevant WAN and public observations through its appropriate support channel, including family, time, equipment arrangement and the application that fails. State whether a VPN or proxy affected the test. Ask a concrete question: does this service use CGNAT, and which supported option would allow the required connection?
After a supported change, repeat the same comparison and test the actual application from an appropriate external network. Keep the earlier result so you can tell what changed. A successful CGNAT investigation ends with an understood network path and a suitable access method, rather than a guess based only on a familiar-looking private address.