http://www.informationweek.com/news/infrastructure/ipv6/229502450?cid=RSSfeed_IWK_News
Pretty good article and a sales pitch to get you to buy the full report. Some observations:
NAT was a stop gap measure to try to deal with the depletion of the IPv4 address space.
http://www.ietf.org/rfc/rfc1631.txt
This RFC is listed as informational.
As is mentioned you can secure IPv6 using IPSec but you do have to enable and then configure it. It is not enabled or configured by default. The upside to this is that once it is enabled then insecure protocols become secure by default. Telnet and FTP pass passwords as clear text. Any packet sniffer will display the username and password exactly as written to a screen or to a capture file. After you enable IPSec then those passwords pass on a secured connection so even though the protocol is insecure the delivery mechanism is secure. You can gain the same by using SSH instead of Telnet and using FTP over SSL instead of just plain FTP. A better solution would be to use SFTP. Then you get into the whole mess with the r-commands which no one likes and should already be disabled on your interior network.
https://secure.wikimedia.org/wikipedia/en/wiki/Rlogin
https://secure.wikimedia.org/wikipedia/en/wiki/Remote_Shell
And just to finish scaring you there is also the X Display Manager Control Protocol
https://secure.wikimedia.org/wikipedia/en/wiki/X_display_manager_%28program_type%29
Not mentioned were early efforts by Novell to try to side step the issues altogether. They had a plan to use IPX clients that connected to a machine and then that machine connected to the Internet using TCP/IP and then passed the data back to the clients using IPX. http://tools.ietf.org/html/rfc1234 The security gain there being that the clients had no way to talk directly to the Internet thereby mitigating the risks involved in connecting to and participating with the Internet. This happened in the early days of the Internet and Netware tanked as the OS of choice for File and Print services and so did this idea. Windows NT being both NetBIOS and TCP/IP aware claimed that space.
The other great area of concern is internally without NAT. With NAT your machines talk TCP/IP to the NAT host and then the host machine connects to the Internet and passes the data back to the client using the traditional TCP/IP mechanism. As the article points out removal of the NAT box since it is no longer required since the address space is no longer constrained presents some issues. The bigger issue is when you have machines on the interior that can all talk TCP/IP.
When NT 3.5 shipped several alarm bells rang because NT Workstation allowed 10 connections to a “Workstation” machine and not a server. This allowed peer to peer connections inside the corporate network to the user’s personal Desktop machine. We also had Unix machines inside the company and for them that was the norm. So we blew it off since NT had only gained a capability that was already present on the Unix machines.
Now you take those same machine and you give them a IP address and remove the NAT box and the fun begins. Without the use of firewall you can peer to peer across the Internet and not just inside of your companies network.
So the removal of a NAT box would require something else to filter the traffic between the corporate network and the Internet. And traditionally that is the firewall machine.
And then you have other methods to secure communications such as a VPN or an SSL connection back to the corporate or personal network.
