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..
It's true that NAT s*cks !
Not just because this means that a few microseconds wil be added in translating the addresses, but because it requires complex changes in protocols.
For this reasn, most protocols of the internet are now tunneled via HTTP, because HTTP can maintain sessions and offer security and transparent proxying. But here the cost in terms of protocols are much worse than NAT. The tunnel is inefficient, but at least it works though wide ranges of devices, thanks to the fact that HTTP does not need to bind the client and the server addresses directly.
HTTP passes very well through NAT, but it is definitely not good for interactive and very dynamic data: the TCP window is a problem (most implementations of HTTP are over TCP, implementations of HTTP over UDP are rare and do not work through NAT without having to use *also* UPnP, and UPnP port mappings are very unstable and require verbose pinging od the network to maintain it live).
But even with HTTPS for using secure channels, it is impossible to resume a session that would be broken. On the opposite IPSEC can maintain a relationship for long and is not restricted to TCP.
But the most important problem with NAT is the rapid exhaustion of port numbers on the shared Internet side, if there are many proxied hosts on the private side of the NAT. With the rapid explosion of connected deviced even at home, it will soon not be rare to have hundreds of devices in our LANs that need to have some connectivity with the Internet. The NAT router will not be able to route them all via NAT, or will have to sacrifice the session lengths (as can be seen in Europe on mobile Internet networks that are extremely unreliable to keep sessions for more than a few minutes).
NAT is effectively unworkable on mobile networks. With the 4G/LTE coming, users will want to have routers in their home using it and double NAT (on the mobile access etwork and on the hme router) will fail (or the performance will be dramatically slow).
We do need IPv6 now because of 4G/LTE and because of connected appliances everywhere. And we don't want IPv6 relyed over an IPv4 tunnel (like it is currently deployed by European ISPs: this is extremey slow, and such tunnels require a proxying server hosted by the ISP itself, and we all know that these servers can't cope wit hthe traffic and don't scale.
We want IPv6 directly in the routing layer, not via a presentation protocol such as proxied tunnels. 6to5 and Teredo are just transition mechanisms not designed to be used for long, and certainly not for use by modern demanding applications such as HDTV, VOD, and VOIP, which have strong requirements in terms of performance (not just in terms of average bandwidh, but also in realtime adaptation of the trafic and good response time).
Suppose you have an media broadcast: the broadcaster cannort support many connections from clients. They want a single point of inlection to broadcast most of thee trafic needed, even if there's a separate low-volume channel for the nteraction (such as querying back the missing data and returning this data over this secondary channel to clients.
But note that this secondary channel should often have higher QoS priority to ver delivered to the client. But what will happen on the client side if all its channels are routed via the same NAT router ? IT will be impossible to manage QoS correctly. Note that broadcast (or subscribed multicasts) do not work over HTTP or any other protocol based on TCP, they need UDP.
"We do need IPv6 now because of 4G/LTE and because of connected appliances everywhere."
One other aspect of 4G that demands IPv6 is Voice over IP. With 4G, voice calls are supposed to be carried via VoIP. With VoIP, you're supposed to have end to end IP connectivity between phones. There are nowhere near enough public IPv4 addresses for this to happen. If the carriers don't provide IPv6, then they'll have to provided gateways to convert NAT to some shared address and go from there.