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