Re: [v6ops] Thoughts about wider operational input

[Nick Buraglio <[e-mail]>]

On Tue, Apr 5, 2022 at 4:53 PM Mark Smith <[e-mail]> wrote:

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

Even this is becoming less and less of a "must have" with services that
provide voice services over packetized and encrypted channels. I suspect in
a decade or two a global PSTN number won't be a hard requirement for a
voice/video/chat service. We're already well on that path, but I digress.


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

While I am vehemently in favor of end-to-end connectivity and reducing
reliance on address translation, this is not really a good analogy and
sends the wrong message. In many cases, inbound connectivity is undesirable
and, to relate it to the PSTN references, there is a booming market of
filtering inbound calls precisely because of the open, end to end
connectivity. War dialing is still *very* much a thing as well and there
are few if any ways to mitigate such things at scale and within reach of
those not running a PBX, at least in my experience in the US.


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

I'd love it if my phone never rang =)


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

I think that boat has been at sea for a long time. It doesn't matter what
the original intent was, we have to adjust to the reality of what is
dominant in operational deployment for absolutely vast swaths of end-user
and business-user internet. I am no fan of address translation, and have
given countless talks on the merits of end-to-end connectivity for
scientific networking, but translation is a tool in the toolbox that there
is almost zero chance of going away, and I have consistently gotten
questions about it from institutions that I am working on v6 deployments or
plans with. I suspect others have had the same experience. As said before,
this is not a technical problem to solve, it just happens to have technical
aspects in the execution. If we want IPv6 deployment to happen at the
layers that we've been talking about (non-service provider, non
cloud-scale, non-mobile), we have to at the very least be sitting at the
same table, and right now I don't think we are even in the same room
because what is expected, and by all intents and purposes "required" is
vastly different that what is being discussed here.  We have to be willing
to go to their table and have a conversation, in many (most?) cases the
table we are at is wholly unknown to "enterprise".
At the same time, IETF may be too far down in the weeds for that table, as
most enterprises want solutions (i.e. tell me how my requirements can be
met) and not standards (i.e. this is how the protocol is supposed to work).

I think the real question is "how do we make the best use of what is
available and operating at scale?" and "how do we engage with those that
are educating and deploying /for/ enterprises.


Respectfully,

nb


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