Re: [v6ops] Thoughts about wider operational input

[Chris Cummings <[e-mail]>]

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

I know that you called out mobile phones specifically, but since we're
talking mainly about enterprises, I think that a PBX is perhaps a more
appropriate comparison. Businesses have been running PBXs with private
extensions for their phone numbers for decades, and it is a
well-established pattern. It's actually almost a perfect analog in my mind
for NAT/PAT. I, of course, don't like NAT and love end-to-end connectivity,
however, to Nick's points here, lack of end-to-end connectivity is a very
well-established pattern for most enterprises, just like private extensions
on a PBX.

I think that different networks (mobile vs PSTN, mobile data vs
enterprise/campus LAN) have different expectations and different
requirements for things, and that's what I think is important to keep in
mind. There is no "One Right Way" to run a network, and it's not our job
as IETF participants to deny the use of a specific technology, I view it as
mainly to set standard ways of doing things and BCPs, but not to be the
network police.

Chris Cummings


On Wed, Apr 6, 2022 at 9:34 AM Nick Buraglio <[e-mail]> wrote:

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