Re: [v6ops] Thoughts about wider operational input

[Simon <[e-mail]>]

David Conrad <[e-mail]> wrote:

> On Apr 2, 2022, at 10:37 AM, Simon <[e-mail]> wrote:
>>> What you dont know is what IP address YOU have from the point of view of the other endpoint.
>> Indeed, and that’s why Nat == broken. Pretty well the entire foundation of networking falls over if you have no idea who *you* are.
> 
> No. An IP address identifies and locates a connection point for IP service.  What is behind that service, including identity, is determined by higher layers. The service connection point could be a single process, or multiple processes, or, in the case of NAT, an entire network. You cannot rely on an IP address alone as any indication of “who *you* are”.

Again, that’s starting from what we have now (NAT) and working backwards. It’s not working from how IP was designed and working forwards. The IP address is an identifier for routing network traffic to that endpoint - and it should be globally unique and globally routable.

>> That is the foundation of IP - globally unique addresses, so that an address can only refer to one end node;
> 
> Even ignoring NAT, no.  See, for example, https://datatracker.ietf.org/doc/html/rfc4786.

A classic diversion tactic - when it looks like the argument is being lost, bring in something that’s irrelevant but which looks like it supports your case. Anycast cannot be considered equivalent to NAT - to start with, it does NOT mangle packets.
True, it is a case of non-unique addresses - but it is also a special case where all endpoints sharing that address have been explicitly configured to share serving a service on it - it works well for session-less services like DNS; not well for session orientated services. Because of the known limitations, you wouldn’t (for example) serve up a SIP registrar behind Anycast without putting in a lot of careful engineering to work around those limitations (e.g.) by having state synchronisation between the different servers.
Unlike NAT, each endpoint knows the globally reachable address; unlike NAT, each endpoint with that address is serving the same thing; unlike NAT, it is merely a case of routing packets slightly differently without mangling the content of those packets.

> 
>> and end-end communication, so any end node can communicate with any other end node. NAT plus private addressing breaks this - I can tell someone that I’m at 192.168.1.1 and that doesn’t differentiate me from the thousands or millions of other 192.168.1.1 nodes in other 192.168.0.0/16 (or 192.168.1.0/24) address spaces; nor does it enable them to send a packet to me. I.e. the network is broken.
> 
> 
> Given the vast majority of Internet users (including myself, don’t know about you) are behind NAT boxes and we’re having this conversation, I gather you’re using the term “the network is broken” in a non-traditional way.

Again, it’s easy to declare something as “not broken” when you redefine broken to not include the inconvenient cases. It reminds me of the old joke about “How many Microsoft engineers does it take to change a lightbulb ? None, they simply redefine the industry standard to dark !” You are re-defining “works” to have a different meaning - for your argument, works must be “works for simple things **I** care about”; for others, works means “works for all types of traffic including protocols/services not yet dreamt up”.
As I have pointed out, NAT doesn’t (mostly) break simple client to server arrangements such as mail client to mail server and web browser to web server (the centralised model of the network). It does break a multitude of other cases. And as already highlighted in a previously referenced RFC - it does act as an obstacle to the introduction of some types of new service.

> All communication over IP must be demultiplexed by higher-layer processes via protocol and/or port. NAT adds an additional form of demultiplexing, mapping a single address plus port into multiple addresses.  NAT breaks things because higher-layer protocol designers violated layer boundaries, granting those higher-layer protocols knowledge of lower-layer identifiers, which should have been opaque.

No, you are moving the goalposts again. That basic demuxing by protocol and port happens WITHIN the endpoint - where there are well defined methods for any application to understand the little bit of the network it needs to, such as IP addresses it may bind to, and ports which it may use. That is not a violation of network layers.
NAT happens OUTSIDE of the endpoint, in the network, where applications are unable to query for the basics and thus have to build in various methods to try and second guess how their packets are being mangled by what should be a transparent packet transport. Arguably, this is a violation of protocol layers - each application needs to have an intimate knowledge of how networks might behave, so not simply a case of asking the OS what addresses are available to use and needing no knowledge of routers and gateways, but needing to understand how packet handling operates after the packet has left the end-point.

I’ll go even further. If an application querying the local OS (or more technically, the network stack) for available addresses and ports is a layer violation, then presumably you would argue that having (e.g.) a web server bind to a specific port is also a layer violation - after all, it’s job is to merely server pages, not to have any knowledge (by your suggestion, any knowledge AT ALL) about the underlying network.
If you don’t argue that, then you are arguing that knowledge of addresses and ports IS a layer violation; and also arguing that it ISN’T a layer violation at the same time.

> Given the actual endpoint of communication (i.e., the application) cannot rely on the IP address

Only because you’ve redefined networking to suit that argument. I doubt many people would agree.

> , swapping out one IP address for another should have no impact on the integrity of the communication.

It doesn’t as long as the application is able to determine that. But other than for stateless (or short lived session) protocols, changing out the IP address is going to break stuff NAT or not. If your upstream renumbers you, then session break. If NAT is there, stuff breaks until the applications work out what’s happened (potentially long recovery time); without NAT, the OS (or network stack) can tell them when it happens.


> The fact that current applications have intimate knowledge of the underlying identifiers means e.g., changing an endpoint’s connection to the IP network topology fatally breaks communication. This is not a feature.

Indeed, and NAT does that - it changes an endpoint’s identifier

> However, bringing this back to the original question: if you want to bring more enterprises into the IPv6 fold, arguments about how NAT is evil are worse than a complete waste of time, they’ll probably result in your input being ignored.

No, but an argument that NAT does break things in ways that cause costs to the business is a way forward. And NAT does have costs to most businesses - even though most don’t realise it.
I’ve done support, I’ve done the “trying to figure out what’s wrong in the network” stuff, I’ve done the grepping through NAT tables to figure out which stream at one end belongs to the particular client behind the NAT to isolate only that client’s traffic, ... NAT hardware costs money, support calls for when it goes wrong cost money, ... But those costs rarely appear anywhere but as part of a bigger “support costs” line in the accounts.

> For good or ill, NAT is embedded into the architecture of the Internet for the foreseeable future (IPv4-only devices are not going to magically vanish)

I don’t suggest they are - and we already know that the problems with NAT are already getting worse with a layer of CGNAT followed by a layer of end user NAT.

> the benefit of deploying IPv6 is overwhelmed by the risk and cost.

Again, you are conflating two different arguments.
I, along with many, are on the side that we know NAT has a lot of issues and breaks stuff - even you acknowledge that it breaks stuff, you just argue that the stuff it breaks shouldn’t be there anyway. But given the change to do things over (which is what IPv6 offers), surely we should learn from past “mistakes” and not build in the same problems ?

Other than “it’s all I understand” (and I’ve met a few so called network engineers who literally could not understand a network without NAT), I have seen only ONE (yes, just ONE) valid use case for prefix translation (not address and port translation) in IPv6. I’m a bit on the fence as to whether the problems allowing NPT would cause outweighs the problem it would (sort of) solve.


Simon