<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 10 Mar 2022, 11:22 Masataka Ohta, <<a href="mailto:mohta@necom830.hpcl.titech.ac.jp">mohta@necom830.hpcl.titech.ac.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Saku Ytti wrote:<br>
<br>
> Same. And if we don't voluntarily agree to do something to it, it'll<br>
> be the same in 2042, we fucked up and those who come after us pay the<br>
> price of the insane amount of work and cost dual stack causes.<br>
<br>
Indeed, we don't need IPv6 at all at least for the next 20 years,<br>
which is long enough to have 32bit port length for TCP and UDP to<br>
make NAT save address space more efficiently.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">Rather than fudging it at the transport layer, there's always a network layer solution. NAT with port overload got us this far, but it requires state to be stored in the forwarding path. MAP-T limits the range of ports at the CPE, allowing simple algorithmic translation without any stored state in the provider network.</div><div dir="auto"><br></div><div dir="auto">That sufficiently kicks down the eyeball side for some considerable time, but there's still no decent reason to go dual-stack on the content side, except for resource starvation costs in address heavy environments like container clouds etc.</div><div dir="auto"><br></div><div dir="auto">What you end up with is NAT overload islands there too, with gateways/proxies providing the dual-stack, and using TLS SNI for virtual hosting where protocols don't otherwise support it, and the strong discouragement of putting network layer information inside protocols (things requiring ALGs like FTP etc). That's kinda where we are today anyway.</div><div dir="auto"><br></div><div dir="auto">Honestly, I can not see IPv4 dipping below 90% of hosts addressed with it in this decade. That doesn't mean IPv6 is <10%, that means IPv4 remains a near-mandatory service requirement for the bulk of addressable hosts.</div><div dir="auto"><br></div><div dir="auto">Oh and before I get flamed by a certain person -- if you refuse to support IPv4 and label people fools for not supporting IPv6, you'll just end up with someone crazy like the ITU-T taking over IPv4 maintenance. No-one wants that. Carrot, not just stick.</div><div dir="auto"><br></div><div dir="auto">M</div></div>