IPv6 woes - RFC

Thu Sep 23 20:13:17 UTC 2021

On Thu, 23 Sept 2021 at 21:48, Christopher Morrow <morrowc.lists at gmail.com>
wrote:

> This sounds like very naive nat state management behavior.
> Ideally, you'd  be able to maintain state of:
> original-src/dst/ports/proto -> in-interface/external ip/port/proto
>

What you describe is called symmetric NAT and is the kind which has the
highest impact on customers. Many NAT traversal techniques fail to work
with this type of NAT. STUN does not work with symmetric NAT.

You purposely want a lesser NAT type which makes NAT traversal easy. This
enables more applications to function despite the NAT. Almost every CPE
avoids symmetric NAT for one of the lesser types for this reason.

>
> unless some internal/original src is double using port/proto ... you
> should really
> have the ability to nat quite a large number of things to a single ipv4
> address.
>

There is no point in optimizing your customer per public CGN IP address
ratio and multiple reasons for not doing so. At some point you will
experience attacks on the CGN address or blacklisting in online games and
so on. Having less customers affected each time that happens is better.

In our network approximately 10% of new customers signed up within the last
year have asked to escape the CGN and get a public IP. This means I need
100 IPv4 addresses per 1000 new customers. Plus 4 IPv4 addresses for the
CGN server. What difference would it make if we could optimize those 4
addresses to be just 2 or maybe 1? What if it caused just a couple more
customers to request a public IP address because they got annoyed by a more
restrictive NAT or by failed sessions?

Regards,

Baldur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210923/8b4f53e8/attachment.html>