On Wed, Jun 17, 2026, 11:20 Douglas Fischer via NANOG <nanog@lists.nanog.org> wrote:
To consider that the entire problem lies solely in the stateful table of outgoing and incoming connections is bordering on lack of knowledge.
[...]
So... The real goal of IPv6 is not about using hexa ou integer to do some pings... Is about the communications being end-to-end and allowing non-server-centricity is precisely to get rid of all these little add-ons with each new application that is born on the Internet.
So again I ask--are we saying the only answer for uplink redundancy in IPv6 should be to get an ASN and PI address space and add another entry into the DFZ routing table? Or do you have some other solution for redundancy in IPv6 that hasn't been mentioned yet that doesn't involve BGP (which inflates the routing table size) or NAT66 (which breaks the purity of the end to end communication flow you think is the whole purpose of IPv6)? Because if you don't, I think you will have very effectively made my point for why IPv4 is never going to be replaced by IPv6. :/ Matt
Em qua., 17 de jun. de 2026 às 14:49, <sronan@ronan-online.com> escreveu:
NAT is fine (1:1), PAT is the cancer (1:Many).
On Jun 17, 2026, at 1:40 PM, Douglas Fischer via NANOG < nanog@lists.nanog.org> wrote:
NAT is cancer! NAT in IPv6 is spreading cancer cells to all the organs of a new, healthy body.
NAT it's not just translate addresses... It needs to deal with the applications upper layers. NAT breaks everything that uses side-connections like P2P communications.
In other words, this idea that NAT66 can save dual-isp-home connections its a lie... It breaks the applications. Especially the end-to-end applications.
Suggesting this kind of solution just reinforces the cloud-server-centric non-opt-outable that we already live with. That is the work way to go!