Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis

["Ackermann, Michael" <[e-mail]>]

Thanks to Nick and Lorenzo for their comments and I believe this is an important discussion.
As an enterprise network operator I do not feel NAT is great, and it causes several management, diagnostic and performance issues.  But (there it is), I do not have yet have a good alternative to sell.  IPv6 deployment could address some NAT situations, but most of the enterprises I work with are still resistant.
A viable alternative to NAT would be a good reason to deploy IPv6.

From: ipv6 <[e-mail]> On Behalf Of Nick Buraglio
Sent: Wednesday, March 27, 2024 11:50 AM
To: Lorenzo Colitti <lorenzo=[e-mail]>
Cc: 6man WG <[e-mail]>
Subject: Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis

[External email]


On Tue, Mar 26, 2024 at 8:31 PM Lorenzo Colitti <lorenzo=[e-mail]<mailto:[e-mail]>> wrote:
On Tue, Mar 26, 2024 at 6:33 PM Ole Troan <[e-mail]<mailto:[e-mail]>> wrote:
The benefit of NAT class mechanisms, is that cost and benefit are aligned. Only one side needs to deploy it.

Actually, the benefit of NAT class mechanisms is that one party deploys them and another party incurs the costs. NAT is great for the network operator, because it moves a number of problems out of the network operator's domain. But it doesn't do that by solving the problem, it does so by making the application's job more difficult.

I don't think that is typically true. I will definitely say from experience that there is a significant operational cost to deploying any translation tool, and more so when there is active state tracking and overload involved. There are often (but not always) logging requirements to do these things at scale, and there are definitely operational costs in dealing with state table tracking and scaling. These don't exist at the same level for mechanisms that do not track state and that do not masquerade using port address translation. They may still incur application cost, or they may not, that is always going to be based on the application stack and is more likely in real time applications that don't use a third party intermediary, as you have stated.
There are similarities in the translation toolkits, yes, they all perform translation at some level. However, what is generally referred to as "NAT" in the general term is typically PAT or NAPT or Masquerading, depending on the nomenclature. That said, *because* it is significantly easier to deploy NAPT, I do not believe that it is an apples to apples comparison. They're all tools in the "translation" category, but they're definitely not all created equally. NPTv6 does a 1:1 translation, the NAT that folks seem to be referencing in the IPv4 world does not, and I do not believe it is a reasonable comparison.  It's a far better comparison to say that NPTv6 is like a traditional one-to-one NAT (which does still have notable, albeit significantly fewer considerations, which I believe are noted in the draft).


nb

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.


This message was secured by Zix(R).