@craigj2k11 wrote:
The reason matters becuase it wouldnt be done, you would have an IP address for each DNS server.
Well... yes, that's what you'd do. That's been my point this whole time: we need IPv6, because there isn't enough space to do that in IPv4. (Although I don't understand why you would bother NATing; if you have IPs for the servers then just assign the IPs to the servers. No need to make your life more complicated that it already is.)
But Nutty667 suggested I can simply do some port forwarding and be happy. I asked my question in an attempt to point out that it just can't be done in this situation, which means that NATs are not sufficient as a solution.
There's also the unaddressed issue of what will happen when VM end up with more customers than IPs. At that point, they'll be forced to do NAT themselves. How would you configure port forwards when the NAT isn't run by you and is completely out of your control?
There are other issues with NAT too, for instance the network clashes you get when two companies merge their networks or create a VPN between them, or when they create VPNs to employees' home networks. The problems those companies have when they run out of private IP space. The squatting on public space that e.g. Hamachi does to avoid clashes, which makes parts of the internet inaccessible to people using it. The problems caused by machines having a different IP on the local network vs externally, such as the need to configure and maintain split DNS or the protocols broken by it. The need to invent, and implement in all software/hardware, protocols like UPnP and STUN, debug the implementations and maintain external servers for those protocols where applicable. The problems caused by people getting their NAT implementations wrong (for instance routers that can't handle anything that isn't TCP/UDP/ICMP, or that can sorta handle it but fail to provide UI for configuring how it's handled), or things like the SuperHub and NAT acceleration causing breakage for some people. The hardware needed to handle NAT at speeds fast enough for our current and future networks.
And let's not forget the costs of all of the above. You need to understand the workarounds, buy appropriate equipment and software and spend effort setting it up, but then also on maintaining it and debugging it when any part breaks. The maintenance is an ongoing cost, forever, which is not small now and will only get worse as we try to stretch v4 even further. IPv6 deployment may cost money now, but some of it is integrated into existing upgrade cycles (for instance the need to upgrade a cable network to DOCSIS 3: VM are already doing that rollout for reasons that have nothing to do with IPv6) and it's a one-time thing that removes the ongoing maintenance cost of the pile of NATs and the workarounds associated with them.
I include all of the above issues in my "NAT is bad and we need IPv6 to get rid of it" position. It's perfectly ok to be ignorant of most of those issues; they're mostly just part of the everyday business of maintaining a network which is left to network administrators. But ignorance of the problems does not make them go away, and does not magically make NAT a viable solution for the future of the internet.
And just to head off the next few posts: if you are going to claim that removing NAT makes you oh-so-insecure, then you need to explain why you think that replacing the NAT with a stateful firewall that has a default-deny inbound policy doesn't give you that security back. (Because it does.)
