Re: [v6ops] Thoughts about wider operational input

[Simon <[e-mail]>]

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

> JORDI PALET MARTINEZ wrote:
>> Because if you don't have NAT, you are forced to properly configure a firewall.

> That is backwards.

ONLY if you start from the premise that NAT is not in fundamental conflict with IP basics - namely that “packets can be routed from any end point to any other end point” (with the modern security proviso of “subject to administrative policies”.)
In any case, I’m used to configuring a firewall anyway. Most CE devices come with a stateful firewall installed and configured - most of them even with sensible defaults !

> NAT is an operational requirement. You have it because without it something does not work the way you want it to.

Not for IPv6. You are applying the “lets take IPv4 with all its faults and tack on some extra address bits” attitude. We should be taking the opportunity to fix the things that weren’t perfect/right with IPv4.
And for the record, in my last job we were lucky enough to have a whole /24 to play in - and we did, without NAT for the most part. And guess what, it worked very well thank you.
NAT is not strictly an operation requirement anyway, NAT is a sticking plaster on the festering sore of insufficient IP addresses. I would argue that NAT is the fundamental evil that is holding back adoption of a proper fix to the underlying problem - because it’s been “sold” as a solution by people who do not also mention that it’s broken and should be treated as a stopgap at most rather than the saviour of the internet it’s been hailed as.

Most of the discussions in this thread have come down to “the problems with NAT haven’t been a big enough pain point to trigger properly adopting IPv6” - mostly because many of the people making the decisions don’t actually get to see the problems and costs they are subjected to.
In a way there’s a parallel with the Y2k problem - I was one of many IT people doing work up front only to have both users and management ask “so what was the fuss about”. Of course, by fixing most problems invisibly up front, and the remaining ones as they cropped up, management never saw the underlying problem.


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

>> 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 :

> In OSI speak thats a layering violation. An upper level protocol incorporates details and assumptions about lower layers as part of its operations.

Citation ?

> Unfortunately, TCP/IP and its application protocols are rife with them. Well more than one should expect were proper attention have been given to ensure that there was absolutely no equivalent proper way to do it.

So do you agree that HTTP is fundamentally broken then ? Either that, or it’s a protocol violation to run a service on anything but ports 80 and 443 ? Put another way, it’s a protocol violation to have a link to say my server:8443 ?

> Just because its common and convenient and usually works or can be made to work does not make it correct.

And of course, it’s usually done because it is the most sensible way to do it. Lets look at SIP for an example.

The device (lets assume a simple phone to keep things simple) needs to talk SIP in order to control sessions. But it makes complete sense to use a different protocol to transfer the audio streams (multiple) - and note what I said about the audio streams not necessarily going to the same place as the SIP user registration.
What you’ve said is that it should be “illegal” to allow my phone to exchange audio streams directly with someone else’s phone - OSI layer violation. Yet that is the most efficient way to do it (where it’s possible). The alternative is something like IAX where the application is effectively embedding a chunk of protocol stack - the ability to multiplex the packets of multiple streams inherent in IP (TCP or UDP) over one network - into the application. And in the world where all the traffic must be carried in one session, it means your voice traffic must pass through an “exchange” at both ends, adding delay and jitter as well as processing load to what would otherwise be a very lightweight application.

>> 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.
> 
> In theory, the protocols are broken. If they hadnt taken the easy way out, we would not have to work around so many of them.

Again, citation. According to whom, other than the “NAT is beautiful” brigade are they broken ?

> RAM is cheap.

Not in many lightweight devices it isn’t.



Simon