Re: [v6ops] Thoughts about wider operational input

[Simon <[e-mail]>]

On 30 Mar 2022, at 07:31, Chongfeng Xie <[e-mail]> wrote:

> Hi， Mark，
> Some enterprises do not want to expose their real address in the network to the outside, so they will use NAT, whether nat44 or nat64 or even nat66 in the future. Therefore, NAT may always exist with the needs of customers.
> 
> The technology itself is not right or wrong. It is inappropriate to directly state whether a technology is good or bad, but whether the technology is appropriate for specific scenarios. You said there was a lot of issues with IPv6+NAT，under what scenario? What's are the issues ? Is it a stateless IPv6+NAT or a stateful IPv6+NAT?

Any form of NAT breaks things<period> That’s the short answer.

Longer answer, any protocol that embeds addresses in it gets broken - e.g. during session setup one end tells the other, please contact me at address X and port Y. That is quite common once you get past a basic “open connection, squirt some data, close session”. Examples that come immediately to mind :

VoIP: phone registers with an exchange. The exchange need to be able to directly call the phone on a control port (typically the same one used to register) to tell it when a call comes in. The phone then needs to tell the exchange what address and port it wants the voice (and/or video) stream sent to. That stream may come from the exchange, or in the more general case it could come from elsewhere - e.g the two end points exchange the voice stream directly without routing it via the exchange. That is how SIP is designed to work - but in my limited experience is never done because it’s too broken by NAT for it to ever work reliably, instead VoIP providers typically have to provide a proxy service that the phone talks to, and the proxy service has to manage de-mangling stuff NAT broke.

The details don’t come to mind right now, but I believe file sharing in both Windows and Unix (NFS?) tend to have a master (control) service with which the clients talk, and then the actual data transfer is done over a separate connection negotiated between the client and server control processes. So the server tells the client to connect to a specific address and port for the data connection - which is broken by NAT.

FTP: By default uses separate connections for control and data transfer, and needs either an ALG to modify address/port pairs in the control packets, or the client use a specific mode (passive mode ?) to avoid the problem. I vaguely recall the server can contact the client as well - it’s a long time since I delved into the internals of FTP sessions !

And then there are distributed applications - BitTorrent is one well known one that comes to mind. Peers need to tell “the cloud” where they can be contacted by other peers - also broken by NAT.

All of these problems can be worked around to some degree or other, but the common factors are :
They don’t work (typically at all) through NAT without some help. With Bittorrent peers, typically there’s a whole config section to tell it what NAT it is behind, ditto for (e.g.) Asterisk as a VoIP switch. With some NAT implementations it’s impossible to make some fo them work - see below.
They all involve developers, and support people, putting effort into implementing the workaround code and support (e.g. adding the settings to the config pages) and users waste effort getting them set up right. All effort that could be better put to productive use rather than fighting broken networks.

A few years ago I came across a NAT implementation that defied all attempts to get VoIP through it. Many (IPv4 implementations) try and preserve the port number if that port isn’t already mapped for another internal device, many attempt to keep the mapping stable (i.e. the device appears as the same address and port to all outside devices). These are relatively easy to work through and the device can work out what it needs to do with (e.g.) STUN.
But one implementation really had me wondering WTF - and the vendor straight up said “it’s for security” and didn’t consider “but pity it means some of your devices can’t work properly” as any sort of problem. This implementation actively randomised the port mapping for every connection - not just a different mapping for each outside device an internal device connects with, but on each connection so once a UDP mapping timed out, on the next connection the client was guaranteed to get a different mapping. So while some vendors at least try and make NAT as least damaging as they can, others have gone out of their way to make it truly crippling - unless the sole purpose of the network is to allow a web browser or email client to connect to an outside server.
You remember things like that, and to this day I do my utmost to avoid using or recommending Zyxel kit.




On 30 Mar 2022, at 16:56, Joe Maimon <[e-mail]> wrote:

> NAT is indeed a security layer, because it fails closed and requires explicit permission to allow traffic. Enterprises like that.


NAT does no more than even the most basic packet-filter firewall can do if set to a  default of “deny inbound, permit outbound”. How many decades have all the relevant OSs supported at least a basic packet filter ? What’s more, a basic packet filter needs less resources (no connection tracking table) than a NAT gateway - a stateful firewall will need (I think) a similar level of resources in terms of tracking connections (perhaps a bit less as it doesn’t need to store two address/port pairs for the inside end of each connection like a NAT gateway does).


Simon