On Wed, Jun 17, 2026, 11:20 Douglas Fischer via NANOG <[email protected]> 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, <[email protected]> escreveu: > > > NAT is fine (1:1), PAT is the cancer (1:Many). > > > > > On Jun 17, 2026, at 1:40 PM, Douglas Fischer via NANOG < > > [email protected]> 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! > > > > > _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/6L6FYA5XSDFERI3SUQYNYAZFBSBIT6DO/
