You don't need to be an expert to get such metrics. The fact that there's a DHCP or NAT router on the tower does not hide the other fact that we constantly get the same few IPs being used on the Internet, and being trackable to a single tower, independantly of the user connected to it with its smartphone.
Google is already using this to get a fast alternate geolocalisation of smartphone users that don't include a GPS device (he also uses the geolocalisation of those connected to an open Wifi access, but it's much less reliable, as most of this hotspots are connected to a DSL/cable/FTTH/FTTB access, via a tunnel whose IPv4 is assigned much more temporarily by the upstream ISP, in a address block that covers a much larger metropolitan area). The public IPv4 address used provides the mapping and Google can then correlate this data with the collected GPS coordinates and then compute the location of the cell tower to match it with a good enough precision of the location. These IPv4 addresses are extremely stable, and it's not the DHCP or NAT routing that will hide it.
There are tons of sites that will report you the public IPv4 address they see when you connect to them. Not a big deal. Personnally I will prefer getting this info from a known secure site rather than an unmanaged site or a commercial site that wants to sell you their security solution (using sometimes fake reports...)
Anyway, the "ShieldsUp!" port scan finds nothing on my PC, except its public IPv4 address, and it does not test the IPv6 address through which the test could be reached (does grc.com have an IPv6 address that I can connect to?).
Most personal firewalls today don't handle the IPv6 trafic, and won't block the IPv6 traffic, so port scans via IPv6 used by malwares may still find many more vulnerable clients than with IPv4. With the growing number of Internet users that have an IPv6 connection (even through a tunnel), this may be a concern.
Sometimes, some ISPs did not inform their customers before activating the IPv6 connectivity, this is the case of my ISP, and I noticed it working through a new tunnel only weeks after the change of its router firmware. How lame they can be ! Thanks I was not attacked, because I had previously already used some third-party Teredo tunnels, and preconfigured and checked my security, but may be the Teredo tunnel broker was implementing the firewall itself, but not my ISP.
So I had to check this again to see if I was vulnerable through this new unnoticed tunnel; it looks like my ISP filters (on its Cisco L2TPv2 tunnel) only a few wellknown ports used by Windows file/printer sharing, and outgoing SMTP connections, but nothing else (and there's no IPv6-to-IPv6 NAT: this is a lame bridge sharing data between distinct customers connected to the same L2TPv2 tunnel-broker, which also has severe bugs such as loosing essential IPv6 routing options needed for IPSEC, no longer working; my ISP has now suspended its experimentation and no longer adds new customers; Cisco will have to rework its bogous solution, or my ISP may use another technology for its final deployment)...
I can't edit or delete it, as we're only allowed 15 minutes to do so. Perhaps one of the moderators could do it.
I've deleted it.
I think one thing that a lot of people are over looking is the fact the NAT meant loss of performance. Every packet exiting a NATted network must be translated on its way out, and returning packets must be translated on their way back in.
This is going to need a lot of hardware and cpu/ram time, and lets not forget that some protocols cannot be NATted at all.
These protocols that can't be Nated include for example; IPSec’s AH sub-protocol.
Also NAT obscures matters when troubleshooting, because the addresses are routinely reused by NAT.
There are going to be more things to worry about! i agree that there are not enough IPv4 address, but you don't hear many people discussing the issue of protocols that can't be Nated, and the ultimate cost it is going to incur, to do all of the Nating??
We are all to blame, well most of us, this entire issue should have been dealt with back in the mid 90's when we had already started to run out of addresses, and then we all jumped on the Nat bandwagon.
I will tell you something, i think there is a lot of money to made in the cross over to IPv6, just as there was with Y2K..
Another thing that appears to be forgotten is NAT breaks some protocols. For example, IPSec authentication headers cannot possibly work with NAT, because they verify the IP addresses and ports haven't been changed. NAT also forces VoIP to use STUN servers, so that the other end knows what the real address is for the phone.