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

Reply via email to