Strange Translations
The reasons why some people use http://en.wikipedia.org/wiki/Network_address_translation NAT on IPv4 are varied, among others are usually these:
As stated elsewhere, the firewalling properties of NAT are very weak and very easy to replace with a state-of-the-art stateful firewall (eg. it is just one line in Linux' IPTables implementation). Address amplification is no longer an issue with IPv6, since IPv6 is already the solution for the IPv4 address problem (NAT was only meant as a temporary workaround).
Addressing stability can be a requirement for many networks, where renumbering of the entire network would unduly disrupt operations (for example in many automated production facilities).
Addressing stability can be created several ways:
There are of course drawbacks to NAT: many protocols fail in the presence of NAT without manipulation on the protocol level - for example SIP and FTP (in active mode). This has to be weighed with the need for stable addresses and the cost of other options of keeping addresses stable. Discussions about the merits of any of those options can be quite heated.
The http://www.ietf.org/html.charters/behave-charter.html BEHAVE workgroup at the IETF is (for some years now) trying to come to a proposal for NAT on IPv6, so far they have published the second draft of http://tools.ietf.org/html/draft-mrw-behave-nat66-02 NAT66. It does not exactly constitute consensus, even inside BEHAVE. And it is currently not listed in the IETF's list of active drafts (it expired a while back, while not being elevated to RFC).
The approach of NAT66 is quite different from NAT for IPv4. Whereas NAT in IPv4 put its emphasis on address amplification, this is no longer necessary with IPv6 and NAT66 consequently puts its emphasis on addressing stability while keeping its impact as low as possible. For example NAT66 is stateless, which IPv4's NAT requires the NAT router to track the state of every connection. NAT66 also does not need to now about any protocol above the IPv6 level, since it compensates against changing checksums and avoids port remapping.
NAT66 is specified to translate one /48 network prefix into another /48 network prefix. This is the prefix size that most providers will give to their customers - at least that is what is recommended and what all the early adopters among providers are using. By translating the network prefix only NAT66 avoids the problems of port remapping at the cost of not being able to amplify addresses - as stated above no amplification is not even a low cost with IPv6's address space, while on the other hand remapping would require the NAT gateway to be able to parse potentially dozens of different header types, which can be much more complex in IPv6, than it was with IPv4 where NAT only has to understand TCP and UDP headers.
It uses the bits 49 through 63 to compensate for the shift in checksums, by adding the difference between the checksums of the two address prefixes to those bits. This way the router does not need to look into any other headers and change the checksums there. There is one exception to the direct translation of addresses - NAT66 cannot translate internal networks that contain 0xffff in bits 49 through 63 - this is due to the way checksums are calculated in TCP/IP: they use the one's-complement representation of numbers which assigns the value zero to both 0x0000 and 0xffff.
A nice property of NAT66 is that it maps internal addresses to external addresses as a one-to-one translation. This means that every internal host has an official external address on which it can be reached. Instead of implementing port forwarding, which is much more complicated in IPv6, a firewall simply opens the target address/port pair to make it accessible from the outside.
As NAT66 is currently in the state of a withdrawn draft there are only a few experimental implementations in organisations that did research on the protocol. There are no implementations that are usable on production routers.