That is a theoretical harm, or rather an opinion of such. It is not
supported by the widespread use of IPv4 NAT. In fact the ubiquity of
IPv4 NAT is proof that such criticisms are baseless.
Er, no, it's proof that application designers have found work-arounds
for the lack of address transparency caused by NAT.
"lack of address transparency caused by NAT" is rhetorical. It would be
more accurate to point out that application designers fixed protocols that
were poorly designed in the first place. They do this in order to keep
state as well as NAT. Since statefulness has to be preserved anyhow there
would be no net gain in doing away with NAT. With regard to protocols,
I assume you are not defending the design of SIP/STUN/TURN, ftp, ...
If not please do explain.
NAT "translates" layers 3 and 4 the same way routers translate MAC
addresses. If this is a "work-around" then router vendors have a lot of
explaining to do. I take it you are not seriously suggesting IPv6 do away
with MAC layer translation? Can you explain why not?
A common technique is of course to add an application-specific
endpoint identifier above whatever method is used to punch a
session through the NAT.
What you call "whatever method" firewalls call statefulness. The session
is "punched" by the state engine. NAT is added to that with little or no
overhead. I take it you are not seriously suggesting IPv6 do away with
statefulness? If not then please explain the difference.
There's nothing vague about the complete lack of useful logging
of NAT bindings in the D-Link and LinkSys devices I have used in
my home
It does not take many CPU cycles in the equipment I typically use (Juniper
Netscreen, Cisco ASA, Sonicwall, and various http load balancers). Again,
I assume you are not seriously suggesting IPv6 do away with NAT because
low-end equipment does not implement sufficient logging for your
requirements. If not could you explain again how this is factor in your
anti-NAT position?
Roger Marquis
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
