Talk:Carrier-grade NAT

IPv6 relevance

CGN as presented has nothing to do with transition to IPv6. Its only purpose is for IPv4 address exhaust mitigation. As such the second part of motivation should be removed, unless the scope of the article is widened to include topics like NAT64. 198.228.209.164 (talk) 06:22, 23 March 2012 (UTC)

Removed.Jasper Deng (talk) 06:28, 23 March 2012 (UTC)

NAT44444

Note that if one NAT444 client talks to another NAT444 client, you have in effect NAT44444: five different IP addressing realms concatenated, with only the middle "4" being unique public IPv4 space. While this is not an officially used term, it has been used on NANOG and other informal industry forums to describe the setup. This is, of course, absurd, but it's not only going to happen, it must already exist in many parts of the Internet. Suddelny going IPv6 seems a lot more reasoble than doing this. -- 80.168.165.159 (talk) 16:43, 7 August 2016 (UTC)

Just a blast from the past for people from 2033 to laugh at: The public IP address you see on this post is a NAT4444 client, because the means of physical media access ("modem") became a NAT44 gateway by itself. IPv6 deployment failed, because the IPv6 prefix specified in 3GPP standards is not large enough for prefix delegation. As a result, this client stays IPv4-only. -- 46.114.107.170 (talk) 06:12, 31 December 2023 (UTC)

Law enforcement problems

As you might know, its not possible to trace the activities of a single user on a CGNAT network. The article did hint that logging the internal and external IP mapping would help, but its not true. Even if you know who did have which internal IP at which time, if 2 or more users share the same IP at the same time, its completely impossible to find out who did what.

To take an example: Imagine 2 users connect, and you have a DHCP log of it: Customer1 connects as 100.64.1.15 mapped to public IP 198.51.100.24 at 2017-10-11 13:10:02.1294 Customer2 connects as 100.64.1.16 mapped to public IP 198.51.100.24 at 2017-10-11 13:11:16.8712

Now 198.51.100.24 uploads child porn to a website at time 2017-10-11 13:15:10.3729.

Now, even with the above log, you will impossibly find who of Customer1 or Customer2 did it. The only way to actually be able to trace the activity, is to log the content of the communication. Preferable in a way that allows very compact data storage, but still allows searching for key words. This requires a so called "SSL Decryption Proxy" where the customer have to import a CA Root Certificate in his browser.

Sebastiannielsen (talk) 11:59, 11 October 2017 (UTC)

Lol, no. It's not a 1:1 NAT. Like almost all "NAT" it's technically NAPT. So there is a lot more useful information in the state table than just IPs. It's more like:

Customer1 connects to outside host tcp/203.0.113.67:443 as tcp/100.64.1.15:45678 mapped to public proto/IP:port tcp/198.51.100.24:23444 at 2017-10-11 13:10:02.1294

Customer2 connects to outside host tcp/192.0.2.119:443 as tcp/100.64.1.16:33210 mapped to public proto/IP:port tcp/198.51.100.24:25333 at 2017-10-11 13:11:16.8712

Now 198.51.100.24 uploads child porn from TCP port 25333 to a website on 192.0.2.119:443 at time 2017-10-11 13:15:10.3729.

Now, with the above log, you will immediately find it was Customer2 did it.

The way to be able to trace the activity, is to log the NAPT mappings. You can keep your "content logging" and "SSL Decryption Proxy" and fake root CAs safely stored away with your tinfoil hat. ;-) --173.252.44.52 (talk) 05:19, 18 November 2019 (UTC)