Subject: Re: [v6ops] Thoughts about wider operational input

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 1 Apr 2022 07:15:33 +0000

Hi Joe,

What about the capability to initiate connectivity from the outside?
It is easy for the Firewall - just a rule on the CPE.
It is more difficult in NAT44 where the rule should be on the centralized CGNAT.
It restricts the potential list of services that is possible through NAT.

Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Joe Maimon
Sent: Thursday, March 31, 2022 3:08 AM
To: Mark Andrews <[email-masked]>
Cc: v6ops list <[email-masked]>; JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

>
>>
>>
>> JORDI PALET MARTINEZ wrote:
>>> To demonstrate how NAT is not security, you just need to enable Teredo or any other UDP tunneling traversing the NAT, so the security guys can see that without any special config in the NAT, you can dig a whole on it (Teredo Navalis = Shipworm).
>>>
On 31 Mar 2022, at 02:56, Joe Maimon <[email-masked]> wrote:

>> And then you need to demonstrate how the equivalent would not happen on IPv6.

Mark Andrews wrote:
> The fix is the same in both protocols.  Install a FIREWALL and properly configure it to block port 3544.
> NAT is not and never has been a FIREWALL.
>
> A flat screw drive and a flat chisel can both be used to remove screws 
> or dig out wood.  They both work well at what they are designed to do and not for which they are not designed to do.
>

There is no actual permanent solution for internal to external worm/tunneling protocols, except yanking the plug or equivalent security policy.

There is just blocking the method du-jour. When possible.

All this is irrelevant to my point, which seems to have sailed overhead that Jordi's little demonstration says nothing about NAT and security that it does not also say about a similarly configured IPv6 firewall and hence would be dishonest showboating.

Joe

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Joe Maimon <[email-masked]>
Date: Fri, 1 Apr 2022 07:29:00 -0400

> It restricts the potential list of services that is possible through NAT.
Hey Vasilenko,

Not a fan of CGNAT, most of the positives of NAT shrink dramatically 
once it is being inflicted from one administrative domain onto another, 
leaving them overshadowed by the negatives.

Not sure what you are getting at. Does CGNAT up the stakes for security? 
Not for the worm scenario. Does it make backdoor re-configuration of end 
user CPE less of a desirable or achievable target? Probably, for 
whatever that is worth.

Joe

---

From: Simon <[email-masked]>
Date: Fri, 1 Apr 2022 17:54:45 +0100

On 31 Mar 2022, at 21:43, Joe Maimon <[email-masked]> 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 ?
> 
> https://www.rfc-editor.org/rfc/rfc3724.html
> 
> Since the upper level protocol incorporates lower level properties into its functionality, it is now dependent on them.

Hmm, that is not what that document says. I have to assume you are referring to section 4.2 since everything else is in favour of end-end connectivity.
>    Two key points in designing application
>    protocols are to ensure they don't have any dependencies that would
>    break the end-to-end principle and to ensure that they can identify
>    end points in a consistent fashion.

So nothing about not embedding an address and port into a message (e.g. a setup message for a session) since that doesn’t break the end-end principle, and it doesn’t affect the ability of the network to do it’s job (route packets between devices).
>    Architectural
>    considerations around this issue are discussed in RFC 3238 [5].  This
>    desire need not result in a violation of the end-to-end principle if
>    the partitioning of functioning is done so that services provided in
>    the network operate with the explicit knowledge and involvement of
>    endpoints, when such knowledge and involvement is necessary for the
>    proper functioning of the service.

NAT is not a network “operat(ing) with the explicit knowledge and involvement of endpoints”, it is a process whereby it’s mangling the packets in a way that the endpoint/application cannot (in the general case) reliably determine.

> 6.  Conclusions
>    The end-to-end principle continues to guide technical development of
>    Internet standards, and remains as important today for the Internet
>    architecture as in the past.

So, since we seem to have vastly differing interpretations of what that document actually says, over to you - where does it say that (e.g.) an application should not use network addresses/ports within messages ? The application is already fundamentally tied in with the lower layers - unless it understands IP (whether version 4 or 6) to at least some extent then it cannot use the network. At it’s simplest level, it needs to be able to allocate structures to hold address/port pairs of other devices with which it is communicating.

I’ll toss an analogy out there. I want to send a letter/card/whatever to a friend in the post. I don’t care HOW the postal service works, how it routes items (packets), whether all such items (packets) follow the same route. But I DO need to know how to address an item (packet) so that the postal service can route and deliver it. And I do expect the postal service to deliver it to the right address.
As we all know, with snail mail, the addressing is “quite flexible” and at many points there are humans that can apply common sense. So, taking an analogy for NAT, it’s enough for my item to be delivered to the concierge of the apartment block and he will be able to see it’s addressed to my friend and deal with putting it in the right mailbox. Similarly, this NAT isn’t opaque in that my friend (I assume) will know the address of his apartment block and can provide that to me - along with the apartment number.
A network with NAT is like living in an apartment block that you don’t know the address of. You can look at your front door and see it’s (e.g.) apartment 104 - equivalent to asking the OS for the address(es) of the system interface(s). It takes more effort to find out what address you need to tell your friends so they can have mail delivered to you. Furthermore, (in the general case) NAT (or more precisely NAPT) is finding that the numbers on the mailboxes in the foyer random change all the time - and there aren’t enough mailboxes for you each to have one full time. So while the front door of your apartment might say 104, you don’t have a reliable apartment number to tell friends to address stuff to you at. And, with IP, the addressing needs to be explicit - there no concierge who can sort out incorrectly addressed packets.

Now, while I am generally quite negative about NAT, I can see that there are some use cases to PREFIX translation with IPv6. I would qualify that with it being ONLY the prefix that gets changed - the local part of the address and the port would NEVER be mangled. And I’d also qualify it with there needing to be a simple, well defined, process by which the application may ask the network layer explicitly what translation is in place - i.e. meet the “operates with the explicit knowledge of the endpoints” bit above.
However, that last bit needs every application where it may be needed to be updated with support for whatever process/protocol was designed - much as they did (in a much harder manner) to try and figure out what IPv4 NAPT was doing to their packets.

Simon

---

From: Joe Maimon <[email-masked]>
Date: Fri, 1 Apr 2022 15:59:45 -0400

>>     end points in a consistent fashion.

In a network where devices are free to translate packets addressing 
between them for whatever reasons they want (and this was always true, 
its just that it became prevalent for various reasons and ingrained and 
widespread due to shortage), how are they to ensure that end points are 
identified in consistent fashion?

In other words, applications compliant with this rfc must be secured with AH

Joe

---

From: Simon <[email-masked]>
Date: Fri, 1 Apr 2022 21:52:43 +0100

> On 1 Apr 2022, at 20:59, Joe Maimon <[email-masked]> wrote:
> 
> 
> 
> Simon wrote:
> In a network where devices are free to translate packets addressing between them for whatever reasons they want (and this was always true, its just that it became prevalent for various reasons and ingrained and widespread due to shortage), how are they to ensure that end points are identified in consistent fashion?
> 

Identifying endpoints in a consistent fashion is trivially easy - you use its IP address*. It is only if the network starts mangling the address that it becomes non-trivial. “The internet” has never been "free to translate packets addressing between them for whatever reasons they want” for the simple reason that doing so breaks stuff.
OK, any bit of the network can do things internal to itself (e.g. wrap a packet in another header for transit through a carrier’s network) - but then it would need to undo it at the other end.

As far as I can see, you're taking a starting point that it’s OK for “the network” to mangle packets (specifically addresses), and then using that to justify everything else. You’ve cited an RFC to support your viewpoint, but my reading of that RFC says “don’t mangle packets because it breaks things”.

* Yes, the IP address you use needs to remain stable for the duration of the session.

So, serious question. How do you read the RFC you cited and come to the conclusion that “the internet” has always been free to mangle addresses in any way it likes” ?

Simon

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 1 Apr 2022 21:00:05 +0000

Hi Nick

As a typical clueless enterprise guy, I am not only way behind in responding to  emails and to your note below,  but also attempting to get good info & advice from all the messages on this chain from you and Joe and Simon, Paolo  and many other SME's who have responded.
My belated response to what you wrote below, is that it sounds well thought out,  objective and pretty right on to me,  based on my experiences.
At most organizations I work with or talk to,  NAT is not going away,  no matter what we think or say.   I say sometimes that it has become part of our network architecture thinking.   This was originally due to address limitations and (decreasingly now) due to perceived Security benefits.  You called that address obfuscation and that seems to be the most prevalent security sub driver, I see.   We now have FWs, Proxies, IPS, micro segmentation and many other Security tools and techniques that may obviate the need for NAT in most situations, but like you say,  IT AIN'T GOIN AWAY.

I also agree that enterprises are driven by cost and risk models.   Part of that is that if something appears to be working today, we are concerned that if we change it,  in any way,  that introduces risk.   Another reason NAT AIN'T GOIN AWAY SOON,  even if we do find better alternatives and set new directions.
I personally am in favor of NAT reduction or elimination because my role is primarily: diagnostics, performance and monitoring,  all of which NAT certainly does not help me with.   But in the bigger picture there are those that think they still want/need it, so I accept that.

But what I also say,  to the few enterprises that listen to ANYTHING about IPv6,  is that if we continue to scale NAT up,  at the pace we historically have,  the NAT solution may become a problem or the source of  problems on it's own.    So we need to consider alternatives.  And,  that IPv6 may provide some better alternatives.   I then (if anyone is still listening),  go on to talk about GUA end to end (which I think will be great for some,  but not all situations), or ULAs, etc.      My hope/dream is that these and other alternatives eventually produce deployments with less NAT,  but even in my dreams it may not all be eliminated.

What I would like to know,  from all of you SME's,  is if what I am saying in the previous paragraph, is good advice to prospective IPv6 enterprises and if I should change or add anything?      I definitely do not want to give enterprises any bad advice,  because if we/they finally do go down the IPv6 road,  and have issues,  they will recoil.   And we will have lost another decade.
For example I do frequently get interest & questions about ULA implementations and usually provide caveats that ULA still has some issues that need to be addressed, before enterprises seriously deploy it.   But there are some very good people already looking into this and I have great confidence that these issues will be handled.

So once again thanks for all the great info / advice  and my ears are wide open for more.

Have a great weekend all!

Mike

From: v6ops <[email-masked]> On Behalf Of Nick Buraglio
Sent: Thursday, March 31, 2022 5:33 PM
To: Simon <[email-masked]>
Cc: v6ops list <[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

[External email]
For 20+ years security vendors have conflated NAT and Firewall. That isn't going to go away, frankly, and from the point of view of the security engineer at an organization of a sufficient size, it doesn't matter if it is technically correct or not. Obfuscating addressing is a very engrained design model, largely because of this fact. I believe there is no a way around that at least in the short term, probably also in the long term.
Understanding that what "enterprises" want is going to be driven by two things: cost and risk. Address obfuscation is very, very, very (95%?) present in enterprise architectures. Deviating from that is largely a non-starter because it deviates from existing risk profiles and completely changes the decades old architectures of application proxies and address translation devices in strategic locations and like Joe M. has stated, the fail closed model is by-and-large a requirement for many large organizations.
If we want to understand what the enterprises want, we need to understand their cost models and risk profiles.  Enterprises aren't going to fret much about state tables, they'll buy bigger boxes. They aren't going to worry as much about performance as, say, a service provider or a supercomputing center. They care that their compliance requirements are met [see address obfuscation, default deny, etc.], that their risk remains as low as possible, and that their widget sells.
I hate to say it because I truly want the end to end connectivity, but I believe that address translation with IPv6 is not going anywhere, and in fact, will probably encourage deployment of v6 in the enterprise space.  It's a useful tool to get to where they want to be (again, see risk and cost).
I think we need to rectify the fact that enterprises don't necessarily want end to end connectivity for the above reasons, and I have seen significant evidence pointing to that fact.

nb

On Thu, Mar 31, 2022 at 12:33 PM Simon <[email-masked]<mailto:[email-masked]>> wrote:

> On 30 Mar 2022, at 21:16, Joe Maimon <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 :

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

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

This message was secured by Zix(R).

---

From: Joe Maimon <[email-masked]>
Date: Fri, 1 Apr 2022 17:36:24 -0400

Simon wrote:

> Identifying endpoints in a consistent fashion is trivially easy - you use its IP address*.

Which you know because you have successful communications with it.

What you dont know is what IP address YOU have from the point of view of 
the other endpoint. And the assumption that you do requires that the 
network not change it in any way.

Which if you consider it carefully, there never was any such guarantee. 
It was just the path of least resistance.

>   It is only if the network starts mangling the address that it becomes non-trivial. “The internet” has never been "free to translate packets addressing between them for whatever reasons they want” for the simple reason that doing so breaks stuff.

But you are free to break stuff. So the network was always free to do so 
and building on the assumption that it never would turns out have been 
not the flawless design otherwise thought.

> As far as I can see, you're taking a starting point that it’s OK for “the network” to mangle packets (specifically addresses), and then using that to justify everything else. You’ve cited an RFC to…

Did the network every come with an explicit guarantee that the source 
address of a packet would not get changed once it left the host?

Or was that just an implicit assumption? Citation please.
> So, serious question. How do you read the RFC you cited and come to the conclusion that “the internet” has always been free to mangle addresses in any way it likes” ?

I read the RFC and I see that it says if you are going to use endpoints 
identifiers you need to ensure they are consistent. And if they belong 
to other protocol layers and traverse a network you do not control, more 
than an assumption is required for that sort of reliable behavior.

Joe

---

From: Mark Smith <[email-masked]>
Date: Sat, 2 Apr 2022 13:31:06 +1100

> It was just the path of least resistance.

That's not correct at all.

The IPv4 header checksum covers the SA and DA. They're not meant to be
changed in flight because they're protected by a checksum, used to detect
when they're changed, accidentally (which of course also means it can
detect them being changed intentionally too.)

IPv6 removed the header checksum for performance reasons, however still
preserved SA and DA protection in the transport layer pseudo-header
checksums.

Additionally, IPsec AH strongly protects the IPv4 and IPv6 SAs and DAs
against both accidental and malicious modification. IPsec originally was
mandatory for IPv6, indicating strong protection of SAs and DAs is
required. It was only loosened to suit low powered devices.

>
> >   It is only if the network starts mangling the address that it becomes
> non-trivial. “The internet” has never been "free to translate packets
> addressing between them for whatever reasons they want” for the simple
> reason that doing so breaks stuff.
>

No it was not. Read RFC2993. If there were not architectural or other
implications of NAT we wouldn't have many RFCs identifying the issues with
NAT, protocols to work around their implications (STUN and TURN), nor a
statement from the IAB about not having NAT in IPv6 - see RFC5902.

> > As far as I can see, you're taking a starting point that it’s OK for
> “the network” to mangle packets (specifically addresses), and then using
> that to justify everything else. You’ve cited an RFC to support your
> viewpoint, but my reading of that RFC says “don’t mangle packets because it
> breaks things”.
>

RFC791.

RFC8200.

RFC2993.

RFC5902.

And from a network operator's perspective,

"The Trouble with NAT"
https://blog.apnic.net/2016/10/26/trouble-nat-part-2/

> > So, serious question. How do you read the RFC you cited and come to the
> conclusion that “the internet” has always been free to mangle addresses in
> any way it likes” ?
> >
> > Simon
> >
> >
>

---

From: Mark Smith <[email-masked]>
Date: Sat, 2 Apr 2022 15:47:53 +1100

Hi Eduard,

On Thu, 31 Mar 2022, 00:36 Vasilenko Eduard, <[email-masked]>
wrote:

> Hi Mark,
>
> NPT+ULA are much better than NAPT44 (no port translation), but not ideal
> (applications may encode address too).
>
> The problem is that Business (from small to big) needs Carrier’s redundancy
>
It is mandatory and NAPT44 is the solution for it now.
>
> The “normal” solution needs heavy modification in “Default address
> Selection”, “ND”, prefix distribution (HNCP?),
>
> That is nobody interesting to push.
>
> Hence, NPT is the only alternative. That would be greatly welcomed by
> Businesses that are comfortable with NAT.
>

None of this is going to change IPv6 adoption.

Imagine a company that makes golf balls. Imagine that it would take say $20
000 of staff time to deploy IPv6+NPT (ignoring and assuming there aren't
network equipment IPv6 upgrade costs).

How would having spent that $20 000 on IPv6+NPT (or just IPv6 without NPT)
made or saved the company money? How would it have made golf balls cheaper
to make, or how would have it increased sales of golf balls if there was
unsatisfied golf ball demand?

Now do the same "how does IPv6 save or make money for my business" for any
other type of business.

Even ISPs that deploy IPv6 are doing it for business and financial reasons.
The two first hand instances I have experience with are (a) for marketing
reasons around 10 years ago, because the company liked to consider itself a
technology leader and (b) to save IPv4 CGNAT costs.

Regards,
Mark.

> Eduard
>
> *From:* v6ops [mailto:[email-masked]] *On Behalf Of *Mark Smith
> *Sent:* Wednesday, March 30, 2022 6:22 AM
> *To:* JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
> *Cc:* v6ops list <[email-masked]>
> *Subject:* Re: [v6ops] Thoughts about wider operational input
>
>
>
>
>
> On Wed, 23 Mar 2022, 01:55 JORDI PALET MARTINEZ, <jordi.palet=
> [email-masked]> wrote:
>
> Hi Eduard,
>
>
>
> What I meant is that I will like to avoid the issues that NAT creates for
> apps. We must aim for something better.
>
>
>
> This.
>
>
>
> IPv6+NAT creates a lot of the issues that IPv4+NAT does, so why bother
> deploying IPv6 when you've already got the equivalent via IPv4 today?
>
>
>
>
>
> People need to understand why enterprises go to the expense of deploying
> technologies.
>
>
>
> Technology is a means to an end, not the end itself. Technology in
> business either saves money or makes money for the business.
>
>
>
> Enterprises in the 1990s didn't really deploy IPv4, they deployed global
> email and WWW access. Deploying IPv4 was the means to reaching those ends,
> because IPv4 underpinned them.
>
>
>
>
>
> So the questions to think about in the context of businesses and
> enterprises and IPv6 are:
>
>
>
> - What business problem does or can IPv6 solve better than existing IPv4?
>
>
>
> - IPv6 is the technology means to an end, so what is or are the ends that
> are of value to a business, where IPv6 is the better underpinning
> technology than IPv4 to reach those ends?
>
>
>
> - How can deploying IPv6 save or make money for a business?
>
>
>
> Regards,
>
> Mark.
>
>
>
>
>
>
>
>
>
> On the other side, using an experimental protocol for production networks,
> in my opinion is a big “NO”.
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 22/3/22, 13:04, "v6ops en nombre de Vasilenko Eduard" <
> [email-masked] en nombre de vasilenko.eduard=
> [email-masked]> escribió:
>
>
>
> Hi Jordi,
>
>
>
> I understand the desire to fix broken things. (I doubt it is possible)
>
> But why NPT+ULA is not enough for MHMP now?
>
> It is very similar to what Enterprises and small businesses have now.
>
> They would be happy.
>
>
>
> Eduard
>
> *From:* v6ops [mailto:[email-masked]] *On Behalf Of *JORDI PALET
> MARTINEZ
> *Sent:* Tuesday, March 22, 2022 12:34 PM
> *To:* [email-masked]
> *Subject:* Re: [v6ops] Thoughts about wider operational input
>
>
>
> You’re right. Let’s say it in a different way, as may be my first email
> was not clear on this.
>
>
>
> 1.      I don’t think we want again to repeat the NAT problems, so NPT is
> not a valid solution for me.
>
> 2.      I think in the future almost every site could want to be
> multihomed, in some cases “n” links active, many other cases just as a
> backup.
>
> 3.      This means that renumbering is not (probably) a valid choice in
> any cases.
>
> 4.      Can we make PI work in such “huge scale” scenario?
>
> 5.      Can source-address forwarding work and solve all that, or we need
> that and/or something else.
>
>
>
> Only if we solve this, organizations could learn that NAT with IPv6 is not
> the solution, but something better that provides the same results, and no
> need to have “private” addresses, because the way NAT is offering a
> “different” addressing inside and outside is not NAT per-se, but statefull
> firewalling.
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 22/3/22, 10:27, "v6ops en nombre de Ted Lemon" <[email-masked]
> en nombre de [email-masked]> escribió:
>
>
>
> Is it really hncp that we needed here?  I think the key tech we need is
> source-address-based forwarding, and babel i think has delivered that.
> Granted, getting that into soho routers is a problem.
>
>
>
> On Tue, Mar 22, 2022 at 10:11 JORDI PALET MARTINEZ <jordi.palet=
> [email-masked]> wrote:
>
> Maybe the terminology is not the most appropriate and we should talk about
> "organizations", because there are many types of networks that have the
> same problem and those are not enterprises (such as government sites, NGOs,
> etc.).
>
> The problem is the same regardless of the "size" of the organization. The
> difference is that "today" most SMEs don't have that problem because they
> don't have PI, but it may turn the same when they realize that not being PI
> have renumbering issues if changing the ISP. Of course, again, if we talk
> about a "small" SME, then may not be an issue, they only have 40 or 50
> devices to renumber (your mileage will vary), not easy but not "terrible".
>
> On the rest of Gert comments, definitively I agree, and specially on our
> big mistake not working further on HNCP.
>
> Regards,
> Jordi
> @jordipalet
>
>
>
> El 22/3/22, 9:31, "v6ops en nombre de Gert Doering" <
> [email-masked] en nombre de [email-masked]> escribió:
>
>     Hi,
>
>     On Tue, Mar 22, 2022 at 11:42:12AM +1300, Brian E Carpenter wrote:
>     > I agree with Jordi that multihoming is a genuine impediment. What
> isn't generally realised is that it's a problem of scale when considering
> at least 10,000,000 enterprises, much more than it's a problem of IPv6
> itself.
>
>     What is "an enterprise"?
>
>     My stance on this is that for "largely unmanaged SoHo networks" - which
>     could be called "small enterprise" - dual-enduser-ISP with dual-/48 or
>     NPT66 gets the job done in an easy and scalable way (HNCP would have
>     been great, but IETF politics killed it).
>
>     "Enterprise that truly need their own independent fully managed network
>     with multiple ISP uplinks and fully routed independent address space"
>     are probably way less than 10 million...
>
>     Half of them do not want Internet access anyway, just access to their
>     ALGs that will do the filtering and TLS inspection and everything, and
>     then out to the Internet as a new TCP session (= could be done with
>     DMZ islands of upstream-provider-allocated space just fine).
>
>
>     We need to work on our marketing regarding multihoming.  "What is it
> that
>     you get, what is the cost, which of the variants do you want, and
> why...?"
>
>     Gert Doering
>             -- NetMaster
>     --
>     have you enabled IPv6 on something today...?
>
>     SpaceNet AG                      Vorstand: Sebastian v. Bomhard,
> Michael Emmer
>     Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A.
> Grundner-Culemann
>     D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
>     Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>

---

From: Simon <[email-masked]>
Date: Sat, 2 Apr 2022 18:37:55 +0100

On 1 Apr 2022, at 22:36, Joe Maimon <[email-masked]> 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.

> Which if you consider it carefully, there never was any such guarantee. It was just the path of least resistance.

See the refs Mark provided which are quite clear that yes, you have one or more globally unique and globally routable addresses. That is the foundation of IP - globally unique addresses, so that an address can only refer to one end node; 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.

> But you are free to break stuff.

We know that is the philosophy of a number of large corporates (no names, no pack drill), but that is the opposite of what the internet is supposed to be about.

> I read the RFC and I see that it says if you are going to use endpoints identifiers you need to ensure they are consistent.

OK.

> And if they belong to other protocol layers and traverse a network you do not control, more than an assumption is required for that sort of reliable behavior.

That’s a stretch. A reliable network will pass any packet you send provided its validly formed. All I need is a consistent endpoint identifier (address) for myself and the other end.
Note: having an application (e.g.) use multiple ports for different traffic types - such as a port we use for signalling and other ports we use for data streams, and they may mix TCP and UDP, doesn’t change that - that is all within the node and using tools provided by the OS for the purpose. Once that packet leaves my node, the network is not entitled to mangle it. In a transparent network, it is trivially easy to determine what address(es) I can use, and what (for UDP and TCP) ports I can use - I just ask the OS using the tools provided by the network stack.
See the references Mark provided :

> RFC5902.

I’ll add RFC 4924 https://datatracker.ietf.org/doc/html/rfc4924

I’ll quote just one paragraph from that :
> A network that does not filter or transform the data that it carries may be said to be "transparent" or "oblivious" to the content of packets. Networks that provide oblivious transport enable the deployment of new services without requiring changes to the core.  It is this flexibility that is perhaps both the Internet's most essential characteristic as well as one of the most important contributors to its success.

What that is saying is that the internet “took off” as it did because of the flexibility provided by this “packets in one end, unmangled packets out the other” basic principle. It points out elsewhere that when you break this transparency, then you introduce barriers to innovation - if a new idea needs every NAT gateway in the world to be upgraded to add an ALG then that is an effective barrier to the new idea. And as we’ve seen over the last few years, the problems NAT creates have massively assisted the move from “peers” to “consumers” - where we hear regular stories of (e.g.) door bells not working because some service out in the internet isn’t working.

Just for good measure, I’ll point out that the idea of security being achievable by a “hard shell, gooey centre” network is long past. These days the threats are such that every node needs to be able to stand alone and secure itself. Put another way, who cares if the firewall in the gateway is turned off - with NAT, any of those IoT bits of (often cheap and “poorly coded”) equipment could be your attacker, or any device on the network could get infected - it can tunnel out through the NAT, create a reverse tunnel in, and if your other devices aren't adequately hardened than the NAT will have provided very little by way of security. So the point you make that NAT can’t be turned off, that makes it more secure than a firewall is actually the wrong way round - because it’s often described as good security, it instills a false sense of security which is “a bad thing”.
And I write that as someone who has routinely put devices, on public IPs, onto the internet without the benefit of a separate firewall. And yes, they’ve been attacked and survived.

Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 3 Apr 2022 08:52:47 +1200

On 02-Apr-22 17:47, Mark Smith wrote:
...

> Even ISPs that deploy IPv6 are doing it for business and financial reasons. The two first hand instances I have experience with are (a) for marketing reasons around 10 years ago, because the company liked to consider itself a technology leader and (b) to save IPv4 CGNAT costs.

(b) seems to be why ISPs will progressively prefer to push mobile, domestic and SOHO users towards IPv6 and to box IPv4AAS into as small a corner as possible. But what will be the cost that causes ISPs to do the same for large enterprises?

    Brian

---

From: Xipengxiao <[email-masked]>
Date: Sat, 2 Apr 2022 21:08:04 +0000

Hi Brian,

As far as I know, ISPs have the power to move consumers/SOHOs to IPv6, but they don't have the power to move big enterprises to IPv6.  Some big enterprises have moved to IPv6 on their own initiative.  For example, I know one of the big European super-market chains moved to IPv6 for the following reason:

IPv4 address planning:

  *   Store: 1024 * 12000 stores= 12M. (500 addresses per Store is the real need)
  *   Warehouse: 64K * 180 warehouses= 11.52M
  *   Office campus: 64K * 100 campuses = 6.4M

30M of IP addresses is required (Reminder: 10/8 is just 16 million of addresses).

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Brian E Carpenter
Sent: Saturday, April 2, 2022 10:53 PM
To: Mark Smith <[email-masked]>; Vasilenko Eduard <[email-masked]>
Cc: v6ops list <[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

...

    Brian

v6ops mailing list

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 3 Apr 2022 09:32:51 +1200

On 03-Apr-22 09:08, Xipengxiao wrote:
> Hi Brian,
> 
> As far as I know, ISPs have the power to move consumers/SOHOs to IPv6, but they don't have the power to move big enterprises to IPv6.  

Indeed not, but they have the power to make IPv4 more expensive than IPv6, or to convince their customers that IPv6 is more reliable.

    Brian

> Some big enterprises have moved to IPv6 on their own initiative.  For example, I know one of the big European super-market chains moved to IPv6 for the following reason:
> 
> *IPv4 address planning:*
> 
> *30M of IP addresses is required *(Reminder: 10/8 is just 16 million of 
addresses).
> [email-masked] <mailto:[email-masked]>
> 
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
>

---

From: David Conrad <[email-masked]>
Date: Sat, 2 Apr 2022 14:54:09 -0700

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

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

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

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. Given the actual endpoint of communication (i.e., the application) cannot rely on the IP address, swapping out one IP address for another should have no impact on the integrity of the communication. 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.

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. 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) and, with the possible exception of mergers of multiple, conflicting RFC 1918-based networks, the benefit of deploying IPv6 is overwhelmed by the risk and cost. I’d assume most enterprises see the Internet as they do other utilities: a necessary evil (because of the cost) they need to have to get their job done.  I imagine they couldn’t care less about the first 4 bits of the IP header or the length of the address; what they care about is reducing costs and/or improving services. This isn’t religion, it’s business. Understanding, without condescension, what enterprises’ business requirements are would probably be a good first step.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Sat, 2 Apr 2022 15:02:59 -0700

Brian

On Apr 2, 2022, at 2:32 PM, Brian E Carpenter <[email-masked]> wrote:
> Indeed not, but they have the power to make IPv4 more expensive than IPv6,

Why would those ISPs want to push those (presumably) high-value customers over to competitors that aren’t uncharging for IPv4?

> or to convince their customers that IPv6 is more reliable.

Is it? I keep hearing IPv6 kit from vendors is yet to be feature complete in comparison to IPv4 and that IPv6 services by most content providers are generally viewed as an afterthought. Data (as opposed to theory) demonstrating IPv6 is more reliable would be helpful.

Regards,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 3 Apr 2022 11:51:39 +1200

Dave,
> Why would those ISPs want to push those (presumably) high-value customers over to competitors that aren’t uncharging for IPv4?

Sure, this incentive would only become real if the cost difference itself 
was real and exceeded the switching costs.

> Is it? I keep hearing IPv6 kit from vendors is yet to be feature complete in comparison to IPv4 and that IPv6 services by most content providers 
are generally viewed as an afterthought. Data (as opposed to theory) demonstrating IPv6 is more reliable would be helpful.

Yes. My argument is that if became true, it would be an incentive.

     Brian

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 4 Apr 2022 08:51:32 +0000

Hi Mark,
Of course, you are right that the biggest problem for Enterprise IPv6 adoption is the business case.

Broken resiliency (connection to 2 Carriers is not possible) is just a blocking factor that would play only after the business case would be found.

I hope that you do not propose to fix broken IPv6 staff only after a business case would be found.

IMHO: it is evident that the absence of MHMP would strike at some point in time.

Eduard
From: Mark Smith [mailto:[email-masked]]
Sent: Saturday, April 2, 2022 7:48 AM
To: Vasilenko Eduard <[email-masked]>
Cc: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>; v6ops list <[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

Hi Eduard,
On Thu, 31 Mar 2022, 00:36 Vasilenko Eduard, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mark,
NPT+ULA are much better than NAPT44 (no port translation), but not ideal (applications may encode address too).
The problem is that Business (from small to big) needs Carrier’s redundancy
It is mandatory and NAPT44 is the solution for it now.
The “normal” solution needs heavy modification in “Default address Selection”, “ND”, prefix distribution (HNCP?),
That is nobody interesting to push.
Hence, NPT is the only alternative. That would be greatly welcomed by Businesses that are comfortable with NAT.

Imagine a company that makes golf balls. Imagine that it would take say $20 000 of staff time to deploy IPv6+NPT (ignoring and assuming there aren't network equipment IPv6 upgrade costs).

How would having spent that $20 000 on IPv6+NPT (or just IPv6 without NPT) made or saved the company money? How would it have made golf balls cheaper to make, or how would have it increased sales of golf balls if there was unsatisfied golf ball demand?

Now do the same "how does IPv6 save or make money for my business" for any other type of business.

Regards,
Mark.

Eduard
From: v6ops [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mark Smith
Sent: Wednesday, March 30, 2022 6:22 AM
To: JORDI PALET MARTINEZ <jordi.palet=[email-masked]<mailto:[email-masked]>>
Cc: v6ops list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] Thoughts about wider operational input

On Wed, 23 Mar 2022, 01:55 JORDI PALET MARTINEZ, <jordi.palet=[email-masked]<mailto:[email-masked]>> wrote:
Hi Eduard,

What I meant is that I will like to avoid the issues that NAT creates for apps. We must aim for something better.

This.

IPv6+NAT creates a lot of the issues that IPv4+NAT does, so why bother deploying IPv6 when you've already got the equivalent via IPv4 today?

People need to understand why enterprises go to the expense of deploying technologies.

Technology is a means to an end, not the end itself. Technology in business either saves money or makes money for the business.

Enterprises in the 1990s didn't really deploy IPv4, they deployed global email and WWW access. Deploying IPv4 was the means to reaching those ends, because IPv4 underpinned them.

So the questions to think about in the context of businesses and enterprises and IPv6 are:

- IPv6 is the technology means to an end, so what is or are the ends that are of value to a business, where IPv6 is the better underpinning technology than IPv4 to reach those ends?

Regards,
Mark.

On the other side, using an experimental protocol for production networks, in my opinion is a big “NO”.

Regards,
Jordi
@jordipalet

El 22/3/22, 13:04, "v6ops en nombre de Vasilenko Eduard" <[email-masked]<mailto:[email-masked]> en nombre de vasilenko.eduard=[email-masked]<mailto:[email-masked]>> escribió:

Hi Jordi,

Eduard
From: v6ops [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of JORDI PALET MARTINEZ
Sent: Tuesday, March 22, 2022 12:34 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] Thoughts about wider operational input

You’re right. Let’s say it in a different way, as may be my first email was not clear on this.

1.      I don’t think we want again to repeat the NAT problems, so NPT is not a valid solution for me.
2.      I think in the future almost every site could want to be multihomed, in some cases “n” links active, many other cases just as a backup.
3.      This means that renumbering is not (probably) a valid choice in any cases.
4.      Can we make PI work in such “huge scale” scenario?
5.      Can source-address forwarding work and solve all that, or we need that and/or something else.

Only if we solve this, organizations could learn that NAT with IPv6 is not the solution, but something better that provides the same results, and no need to have “private” addresses, because the way NAT is offering a “different” addressing inside and outside is not NAT per-se, but statefull firewalling.

Regards,
Jordi
@jordipalet

El 22/3/22, 10:27, "v6ops en nombre de Ted Lemon" <[email-masked]<mailto:[email-masked]> en nombre de [email-masked]<mailto:[email-masked]>> escribió:

Is it really hncp that we needed here?  I think the key tech we need is source-address-based forwarding, and babel i think has delivered that. Granted, getting that into soho routers is a problem.

On Tue, Mar 22, 2022 at 10:11 JORDI PALET MARTINEZ <jordi.palet=[email-masked]<mailto:[email-masked]>> wrote:
Maybe the terminology is not the most appropriate and we should talk about "organizations", because there are many types of networks that have the same problem and those are not enterprises (such as government sites, NGOs, etc.).

The problem is the same regardless of the "size" of the organization. The difference is that "today" most SMEs don't have that problem because they don't have PI, but it may turn the same when they realize that not being PI have renumbering issues if changing the ISP. Of course, again, if we talk about a "small" SME, then may not be an issue, they only have 40 or 50 devices to renumber (your mileage will vary), not easy but not "terrible".

On the rest of Gert comments, definitively I agree, and specially on our big mistake not working further on HNCP.

Regards,
Jordi
@jordipalet

El 22/3/22, 9:31, "v6ops en nombre de Gert Doering" <[email-masked]<mailto:[email-masked]> en nombre de [email-masked]<mailto:[email-masked]>> escribió:

    Hi,

    On Tue, Mar 22, 2022 at 11:42:12AM +1300, Brian E Carpenter wrote:
    > I agree with Jordi that multihoming is a genuine impediment. What isn't generally realised is that it's a problem of scale when considering at least 10,000,000 enterprises, much more than it's a problem of IPv6 itself.

    What is "an enterprise"?

    We need to work on our marketing regarding multihoming.  "What is it that
    you get, what is the cost, which of the variants do you want, and why...?"

    Gert Doering
            -- NetMaster

    SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
    Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
    D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
    Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________ v6ops mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/v6ops

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
_______________________________________________ v6ops mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/v6ops

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 04 Apr 2022 12:15:15 +0200

What I'm saying is that if you don't have a NAT you will need to ensure that the CPE has a firewall and it is enabled by default. It is not only in the interest of the subscriber, but also the ISP, to avoid calls to the help desk, or abuse cases, etc., etc.

Regads,
Jordi
@jordipalet

El 30/3/22, 22:17, "Joe Maimon" <[email-masked]> escribió:

    That is backwards.

    NAT requires state management to operate. What exactly is forcing the 
    existence of a firewall, let alone its proper configuration?

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

    Firewalls are a security requirement. You implement them because without 
    it something you do not want to work might or even probably will.

    Take car insurance as an example. Even where not legally mandated 
    (anywhere?) its an obvious practical necessity. Yet, uninsured drivers 
    and cars abound on the road. Because lack of insurance doesnt interfere 
    with the ability to operate the vehicle. Its not an operational requirement.

    Operational requirements meet my definition of "force". Security 
    requirements, decidedly less so as has been painfully and universally 
    obvious for decades. Or should be.

    As far as the proper configuration of one? Proving your NAT is 
    sufficiently properly configured. Easy. The firewall? Impractical to 
    impossible, its a negative theorum.

    Restated correctly: Without NAT, you must choose to implement a firewall 
    for it to exist. Perhaps properly. Likely not. Fixed that for you.

    Or:

    Because if you don't have NAT, unless you choose to properly configure a 
    firewall, you will not have one either, properly configured or otherwise.

    >
    > With a NAT, many don't even have a firewall or is not sufficiently well configured.

    Please explain how removing the near universal existence of NAT improves 
    this situation. Do you somehow believe that there will be the equivalent 
    or even greater number of deployments and users who actively choose to 
    deploy firewalling as a result of the global routability of their 
    addressing and the lack of NAT, and that now having made that choice it 
    will as matter of course be followed by the choice to do so in the 
    utmost correct, stringent and sufficient fashion? Farcical.

    At least with the existence of NAT there also exists some level of state 
    management and unsolicited incoming traffic constraints from reaching 
    the internal network nodes. By default, by dint of them being 
    operationally on the internet.

    Joe

    >
    > Regards,
    > Jordi
    > @jordipalet
    >   
    >   
    >
    > El 30/3/22, 17:58, "v6ops en nombre de Joe Maimon" <[email-masked] en nombre de [email-masked]> escribió:
    >
    >
    >
    >      > To demonstrate how NAT is not security, you just need to enable Teredo
    >      > or any other UDP tunneling traversing the NAT, so the security guys
    >      > can see that without any special config in the NAT, you can dig a
    >      > whole on it (Teredo Navalis = Shipworm).
    >      >
    >      > Regards,
    >      >
    >      > Jordi
    >      >
    >      > @jordipalet
    >      >
    >

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 04 Apr 2022 12:20:18 +0200

Yep, that's part of the problem.

I don't think typically "non-home-oriented-CPEs" have an IPv6 firewall, or at least not enabled by default.

"small" SMEs most of the time use the same connectivity as a household subscriber, so most of the time the same "home-oriented-CPE".

If we move to medium SMEs, and of course, enterprises, they should have, in addition to the CPE, a firewall. It may happen that in many cases, they have it, but not neccesarily all.

Regards,
Jordi
@jordipalet

El 30/3/22, 23:16, "v6ops en nombre de Brian E Carpenter" <[email-masked] en nombre de [email-masked]> escribió:

    Jordi,

    As we all know, home gateways that support IPv6 are shipped with a quite adequate default firewall configuration. Is there a good specification for a default firewall configuration for an SME CE router?

    Probably this isn't realistic for large enterprises?

        Brian
    >      And then you need to demonstrate how the equivalent would not happen on
    confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is 
    strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete 
    it.

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 4 Apr 2022 11:20:29 +0000

In reality, it is not easy to have a good firewall and Router at the same time even for a software box.
There were times when I was working for a famous vendor that has a firewall and router as strictly separate devices.
This vendor told Enterprises that it is good because the router and firewall are typically managed by different departments.
And because FW for the Enterprise market should have a lot of features that are not available on combo devices.

My point here: do not assume that it would be easy in all cases to activate FW on the CPE.
Ed/
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: Monday, April 4, 2022 1:20 PM
To: [email-masked]
Subject: Re: [v6ops] Thoughts about wider operational input

Regards,
Jordi
@jordipalet

    Jordi,

        Brian

---

From: Joe Maimon <[email-masked]>
Date: Mon, 4 Apr 2022 08:00:20 -0400

> What I'm saying is that if you don't have a NAT you will need to ensure that the CPE has a firewall and it is enabled by default. It is not only in the interest of the subscriber, but also the ISP,…

Agreed. However the concern is that this equates to an added burden, 
concern, issue that

a) slows adoption of v6

b) does not result in the same level of widespread deployment that the 
included-with-nat basic firewalling has

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 5 Apr 2022 10:46:30 +1200

Indeed, for large enterprises that is true. But surely vendors should be motivated to provide single-box solutions for medium size enterprises?

Regards
    Brian

On 04-Apr-22 23:20, Vasilenko Eduard wrote:
>      As we all know, home gateways that support IPv6 are shipped with a 
quite adequate default firewall configuration. Is there a good specification for a default firewall configuration for an SME CE router?
>      strictly prohibited, will be considered a criminal offense, so you 
must reply to the original sender to inform about this communication and delete

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 5 Apr 2022 07:20:43 +0000

The vendor where I am working now is telling that it is exactly 2x cheaper on OPEX and CAPEX to have 1 box in every branch instead of 2. And claim that there is not any compromise on features for the combo device.
But it does not address the situation if FWs are managed by the security department on the Enterprise side.
And the vendor that is pushing separate devices is still there. They believe that 2x revenue is better.
Ed/
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Tuesday, April 5, 2022 1:47 AM
To: [email-masked]
Subject: Re: [v6ops] Thoughts about wider operational input

Regards
    Brian

On 04-Apr-22 23:20, Vasilenko Eduard wrote:
> I don't think typically "non-home-oriented-CPEs" have an IPv6 
> firewall,
or at least not enabled by default.
>      it.
confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Simon <[email-masked]>
Date: Tue, 5 Apr 2022 20:59:41 +0100

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

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.

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

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

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

---

From: Mark Smith <[email-masked]>
Date: Wed, 6 Apr 2022 07:52:54 +1000

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

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

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

---

From: Greg Skinner <[email-masked]>
Date: Tue, 5 Apr 2022 15:19:30 -0700

> On Mar 21, 2022, at 6:22 PM, Bjoern A. Zeeb <[email-masked]> wrote:
> 
> On 22 Mar 2022, at 1:01, Bob Hinden wrote:
> 
>> In my view, and I think I am agreeing with Nick said, it’s not a technical problem that would be fixed by a technical feature.   IPv4 works for most enterprises today and they don’t see a need (aka business case) to do anything different.   The Enterprises who are thinking about moving to IPv6 are very large enterprises who can’t live within the limits of private IPv4 space.
> 
> But remember that these XXL-enterprises are also seeking solutions and using ways often not feasible or applicable for the common SMLB.
> 
> 
>> I suspect these are the ones we should be talking to.
> 
> I suspect the answer is more like “wait until they start speaking to you”; well, why should they?  IETF is on no radar for most of them ..  so rather you have to go and “listen when and where they speak” because they do.
> 

A place to go where (commercial) enterprise executives meet is a Gartner conference.  They meet virtually, as well as in many cities throughout the world.  However, when discussing IPv6, be prepared for them to ask what you have to offer that will quickly improve their productivity.  Some of them may have read articles such as Networking Hype Cycle 2021 by Andrew Lerner <https://blogs.gartner.com/andrew-lerner/2021/10/11/networking-hype-cycle-2021/?_ga=2.214948631.1699336899.1649137202-1453838395.1649137202&_gac=1.49562642.1649140440.EAIaIQobChMI9dzQ4Jr89gIVghB9Ch1nvgVZEAAYAyAAEgI_4vD_BwE>   The featured graphic indicates that IPv6 is on the “slope of enlightenment,” expected to reach the “plateau of productivity” in 5-10 years.

—gregbo

---

From: Nick Buraglio <[email-masked]>
Date: Wed, 6 Apr 2022 09:32:54 -0500

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

>> >> Indeed, and that’s why Nat == broken. Pretty well the entire
>> foundation of networking falls over if you have no idea who *you* are.
>> >

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.

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

> global number) but from no other carrier?

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

> 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

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

---

From: Nick Buraglio <[email-masked]>
Date: Wed, 6 Apr 2022 09:34:46 -0500

On Tue, Apr 5, 2022 at 5:19 PM Greg Skinner <gregskinner0=
[email-masked]> wrote:

> In my view, and I think I am agreeing with Nick said, it’s not a technical
> problem that would be fixed by a technical feature.   IPv4 works for most
> enterprises today and they don’t see a need (aka business case) to do
> anything different.   The Enterprises who are thinking about moving to IPv6
> are very large enterprises who can’t live within the limits of private IPv4
> space.
>
>
> But remember that these XXL-enterprises are also seeking solutions and
> using ways often not feasible or applicable for the common SMLB.
>
>
> I suspect the answer is more like “wait until they start speaking to you”;
> well, why should they?  IETF is on no radar for most of them ..  so rather
> you have to go and “listen when and where they speak” because they do.
>
>
This has been what we have been doing. So far it has been very enlightening
but not really too surprising.

>
>
> A place to go where (commercial) enterprise executives meet is a Gartner
> conference.  They meet virtually, as well as in many cities throughout the
> world.  However, when discussing IPv6, be prepared for them to ask what you
> have to offer that will quickly improve their productivity.  Some of them
> may have read articles such as Networking Hype Cycle 2021 by Andrew Lerner
> <https://blogs.gartner.com/andrew-lerner/2021/10/11/networking-hype-cycle-2021/?_ga=2.214948631.1699336899.1649137202-1453838395.1649137202&_gac=1.49562642.1649140440.EAIaIQobChMI9dzQ4Jr89gIVghB9Ch1nvgVZEAAYAyAAEgI_4vD_BwE>
>  The featured graphic indicates that IPv6 is on the “slope of
> enlightenment,” expected to reach the “plateau of productivity” in 5-10
> years.
>
> —gregbo
>

---

From: Chris Cummings <[email-masked]>
Date: Wed, 6 Apr 2022 10:37:32 -0500

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 <[email-masked]> wrote:

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

---

From: daveb <[email-masked]>
Date: Wed, 06 Apr 2022 12:15:46 -0400

At 11:37 AM 4/6/2022, Chris Cummings wrote:
> >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.Â

But you can still reach me directly by dialing 
+14125551234 x137. Although I guess that would be 
similar to NAT + Port Forwarding. Perhaps it's 
best to accept the perceived benefits of NAT 
(NAT66) to get the ball rolling and then maybe it 
becomes easier for them to see the value of full 
end-to-end connectivity, and a fairly easy 
transition to remove NAT66 to some/all portions of the enterprise network?

Dave B. (Small ISP that would love to see more enterprise customers take IPv6)

---

From: Nick Buraglio <[email-masked]>
Date: Wed, 6 Apr 2022 13:21:49 -0500

On Wed, Apr 6, 2022 at 11:39 AM daveb <[email-masked]> wrote:

> similar to NAT + Port Forwarding.

------

> Perhaps it's
-----

This is really the point I am trying to make. Just because something isn't
in the spirit of the original idea doesn't mean that it won't be the
prevailing way that things are done. I try to take the approach that "this
may not be the way I'd do it, and it may not be the best - or even a good -
way to build infrastructure, but if it meets the needs and requirements of
an organization, then all we can do is present all of the alternatives and
work with what is decided". Saying "this is the wrong way" won't gain
anything 99% of the time. We can write best practices and advise as to the
spirit of the ideas, but if we want enterprise adoption we have to meet
them more than half way or be ok with them saying "nah, we'll pass on that"
because it doesn't fit in their design/compliance/security model.
Again, I am /VERY/ much in favor of end-to-end connectivity, anyone can see
my track record on this topic if they look around, but I also have had a
lot of experience on making progress in that space and that experience
tells me that asking for complete paradigm shifts without exceptionally
clear and significant advantages well above and beyond what is status quo,
or the solution to a very specific problem that cannot be accomplished any
other way, the answer is almost always a "pass".
Once we can rectify that, then we at least have a point to start from.

---

From: Gert Doering <[email-masked]>
Date: Sun, 10 Apr 2022 18:32:56 +0200

Hi,

> still have globally unique phone numbers?

As long as a mapping mechanism exists that maps my name in people's
address books to a technology that makes my device ring, I do not need
a "phone number".

Your argument sounds convincing, but is cementing the wrong thing - humans
do not want to talk to numbers, but to other humans.  That's a good
identifier - "Aunt Mary".

A phone number (or IMEI...) is more of a locator.

Gert Doering
        -- NetMaster