Re: [v6ops] Thoughts about wider operational input

[Mark Smith <[e-mail]>]

On Wed, 6 Apr 2022, 06:00 Simon, <[e-mail]> wrote:

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

Agree.

For those who disagree, can you give up your globally unique E.164 phone
number on your mobile phone to see how that goes?

Will you be happy to only be able to make phone calls only to those that
still have globally unique phone numbers?

Will you be happy to never receive calls, or only receive them from other
people inside your current carrier's network (where your number is probably
unique ... although perhaps not, since you were happy to give up a unique
global number) but from no other carrier?

The nature of IPv4 (without NAT), IPv6, and the phone network is
peer-to-peer. Any node can directly communicate with any other on the
network, because they have unique addresses.

There's concern these days about how dominant major cloud providers are on
the Internet. NAT and non-globally unique addresses encourages and endorses
that, because it makes receiving inbound application connections ("calls")
either impossible or harder than it should be.

The real question is how have the phone networks scaled globally unique
E.164 number portability, and can we use that technique somehow in IPv6?
I've expected E.164 number portability to fail to scale at some point in
the last 20 years or so, yet it hasn't.

Regards,
Mark.





> >> 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
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>