Daniel, I think you're confused between NAT66 and NAT64. [0]
T-Mobile USA optionally supports IPv6 connectivity in some limited number of new phones (Galaxy Nexus etc) [1], and when the IPv6 option is manually activated by the user^w beta-tester on their phone, then no IPv4 support is provided, and access to IPv4-only resources is available through NAT64 [2] and DNS64 [3]. No dual-stacking is provided; in their slides from [0], T-Mobile USA claims that IPv6-only with NAT64/DNS64 is cheaper than dual-stack with NAT44. Frankly, dual-stacking (with the plain old NAT44) would seem like a better approach for an end-user; I would guesstimate that less than 1% of Galaxy Nexus users on T-Mobile USA have actually enabled IPv6 (and left it enabled after simply testing it), precisely because dual-stacking is not an option, and T-Mo's NAT64/DNS64 must be consumed (instead of NAT44), breaking all those crappy apps that hardcode IPv4 addresses outside of the DNS and such. C. [0] https://sites.google.com/site/ipv6implementors/2010/agenda [1] https://sites.google.com/site/tmoipv6/lg-mytouch [2] http://tools.ietf.org/html/rfc6146 [3] http://tools.ietf.org/html/rfc6147 On 24 October 2012 09:43, Daniel Ouellet <dan...@presscom.net> wrote: > Hi, > > Just saw a few questions and patch for NAT64 on misc and tech@ and I am > really questioning the reason to be fore NAT64 and why anyone in their right > mind would actually want to use this? > > NAT always makes connectivity less efficient anyway and was really designed > to alleviated the lack of IPv4 address years ago and was sadly used as a > firewall setup by what I would call lazy admin instead if a properly > configure one. > > Call me stupid and I will accept it, but regardless of this why? > > NAT was sadly a quick way to setup security and over time become even more > sadly what some security suppose to be expect call the defacto way to do > security. > > NAT needs to process every packets, changed the header both in incoming and > outgoing traffic and as bandwidth keep increasing only make the totally not > optimize NAT table getting bigger as more traffic is present and increase > jitter, latency, etc. Much more powerful router needs to be used and many of > the sadly loved firewall appliance by some admin like the SonicWall and the > like running out of power on intensive UDP traffic and do not allow the end > users to actually get the benefit of their increase line capacity that are > more common these days! > > There is even more then this above, but I will spare the list with more as > my question is really why NAT64? > > IN IPv6, the smallest assigned to remote site is so big anyway and based on > the RFC recommendation to provide a /48 to remote site and even a /56 to a > single house, how could anyone possibly think he/she would even run of IP's > and need NAT64? > > Isn't it just a side effect of a sadly miss guided use of NAT in IPv4 as a > firewall carry over to a IPv6 world instead of starting to do proper setup > now that IP's will be plentiful anyway? > > Anyone have any possible explication that would actually justify the use of > NAT64 that I obviously overlooked? > > Why us it other then for lazy firewall setup these day? > > I would appreciate a different point of view that I obviously appear to have > overlooked as I really don't see why it even exists. > > Best, > > Daniel