[email protected] wrote:
No, nat eliminates all the various translation tables, and the
rewriting of headers that NAT requires. This extra overhead shows in
the form of slower connections when NAT is used.
Yes of course. Except that modern hardware has made this definition of
"slower" meaningless in most if not all use cases.
Also, did you forget (if you are in the USA) CALEA? If you translate
all your customers traffic, CALEA requirements more or less mean you
have to log all that traffic on those CGNAT boxes, which will alone
defeat any of the cost savings of CGNAT.
So? Already the case. Hasnt stopped CGNAT.
Smart ISP's with IPv4 shortages that use CGnat often do port mapping
with their customers so that they do not have to log. A certain range
of ports are provided to each customer, so that no logging is required.
Indeed. Awesome.
And since there are PLENTY of IPv6 addresses, why use effort
processing IPv6 in a CGnat box? That part makes no sense at all. Just
route the packets and be done with it.
Try it in the reverse. Use your cgnat box so that your can IPv6 only
customer nodes that can continue to access the rest of the Internet,
primarily IPv4 nodes.
Honestly, the only reason I can see for NAT on IPv6 is so fallover in
a multihome enviroment that can be handled the same as it is with IPv4
so that BGP is not required for fallover.
The point is that at this time, we should not have to justify nat in
order to permit its standardization. Standardize it and let users figure
it out.
Nat also assumes that noone wants to run their own internet services.
While many things like cameras use a remote server to bypass the NAT
leading to vendor tiein, things are clearly cleaner if each
workstation or other device like a camera can run its own publically
accessable services. Note that this does not mean that firewalls
cannot be in place to block things that are not intended to be world
readable. NAT is NOT a substitute for a firewall.
It is in IPv4. And lets not encourage camera server and devices to be
globally accessible, we already know that is a disaster.
If you want NAT on the networks you manage, go for it. All the tech
bits to make NAT work in IPv6 are there. Just do not expect the rest
of us that would like to get back to the end-to-end model to support
your choice, and I am sure some of your users will wish you did not
make that choice, because of things they want that may not work in
this enviroment.
I expect exactly that. I expect you to support peoples ability to make
this choice, since the current alternative is
a) dictatorial
b) not working
c) delaying IPv6 deployment
Some of the best proponents of v6 is the gaming community, which have
been fighting the limitations of NAT for as long as they have been
around.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
Supporting its existence is not actually the same as supporting its
widespread deployment.
Better it be standardized and move on.
On Tue, 14 Sep 2021, Joe Maimon wrote:
The problem is that No NAT for IPv6 is religious dogma, regardless of
the reason anyone may have for wanting it, which may have nothing at
all to do with address sharing. Even fixing multihoming and
readdressing (to the extent it may be possible) will not eliminate
any and all motivations for NAT. Its time to standardize NAT and move
on.
Now imagine if all those CGNAT boxes are also doing a workable
version of NAT-PT. Deploying customers with any IPv4 becomes optional.
That was supposed to also be read with the same meaning as "without any
IPv4"
Joe
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
