V6 still not supported (was Re: Making Use of 240/4 NetBlock))

Thu Mar 10 19:23:18 UTC 2022

On Thu, 10 Mar 2022, 11:22 Masataka Ohta, <mohta at necom830.hpcl.titech.ac.jp>
wrote:

> Saku Ytti wrote:
>
> > Same. And if we don't voluntarily agree to do something to it, it'll
> > be the same in 2042, we fucked up and those who come after us pay the
> > price of the insane amount of work and cost dual stack causes.
>
> Indeed, we don't need IPv6 at all at least for the next 20 years,
> which is long enough to have 32bit port length for TCP and UDP to
> make NAT save address space more efficiently.

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.

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.

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.

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.

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.

M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220310/fccf0e65/attachment.html>