Egregoros

Signal feed

Timeline

Post

Remote status

Context

2
> There is also a significant set of use cases that currently work better, or at least more easily, with NAT.

> The most common example is small branch sites with dual ISP uplinks. There are a vast number of these sites deployed using two small provider-assigned (PA) NAT pools. This setup is widely understood, simple to implement, and reliable.

> Moving these sites to IPv6 via BGP is often not feasible. Many ISP circuits do not support BGP, and the teams operating these sites lack the time to navigate that complexity. Furthermore, other IPv6 dual-homing options often don't align with enterprise requirements or expected complexity (or really simplicity) levels.

> In my view, this is a core reason why IPv6 adoption remains low in the enterprise space: it requires fundamental paradigm shifts rather than a simple protocol update.

so true
@feld
>There is also a significant set of use cases that currently work better, or at least more easily, with NAT.

This one especially is so obvious, but every time benefits of NAT are mentioned, they get ignored. Not to mention the dumbness of your smart fridge having a network unique and publicly routable address. NAT sucks for hosting on a (home) network, but it also trivial to hide your (home) network from the public just by routing all/most traffic through a node and NATting it there if your setup needs outbound traffic as well. v6 can do the same thing the same way, but uttering the word NAT makes people mad.

Replies

0

Fetching replies…