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

[Mark Smith <[e-mail]>]

On Thu, 28 Mar 2024, 02:50 Nick Buraglio, <[e-mail]>
wrote:

>
>
> On Tue, Mar 26, 2024 at 8:31 PM Lorenzo Colitti <lorenzo=
> [e-mail]> wrote:
>
>> On Tue, Mar 26, 2024 at 6:33 PM Ole Troan <[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.
>

For client/server applications, where the client is on the inside of the
NAT with a private address, and the server is on the outside with a public
address, that wouldn't be typically true.

However, for applications where the communications model is peer-to-peer,
or a mix of client/server and peer-to-peer, the application developer has
to implement RFC 8445 ICE using STUN and TURN for NAT traversal, incurring
additional development, debugging and testing costs.

Alternatively the application developer adopts a client/server
communications model for the application, even though a peer-to-peer model
would be more scalable and more robust against a centralised server failure
and server performance problems.

This is why I say that NAT (of any type) imposes a default client (inside
NAT) /server (outside NAT) communications model at the IPv4 or IPv6 network
layers, rather than the default peer-to-peer model that can then
accommodate both client/server and peer-to-peer applications communications
models.

NPTv6 may be stateless, however since hosts behind the NPTv6 will have to
discover their public addresses via ICE if they want to be peers, NPTv6
still imposes those ICE costs on application developers and the
applications' end-users.

Network engineers who deploy NATs aren't directly exposed to or pay any of
these additional application development costs (other than when they're the
application users), which is why it appears that NAT is a simple and low
impact technology to deploy.

Regards,
Mark.


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