Are people really going to use public IPv6 addresses on their private networks?
Solution 1:
Is that how IPv6 is intended to work?
In short, yes. One of the primary reasons for increasing the address space so drastically with IPv6 is to get rid of band-aid technologies like NAT and make network routing simpler.
But don't confuse the concept of a public address and a publicly accessible host. There will still be "internal" servers that are not Internet accessible even though they have a public address. They'll be protected with firewalls just like they are with IPv4. But it will also be much easier to decide that today's internal-only server needs to open up a specific service to the internet tomorrow.
Are companies really going to set up all their internal machines with public addresses?
In my opinion, the smart ones will. But as you've probably noticed, it's going to take quite a while.
Solution 2:
We use public IPv6 addresses in our company network for all devices.
We use a stateful firewall on our gateway, that:
- allows all icmpv6
- allows new connections from internal network out
- allows established connections from public to internal
No public traffic (except ICMP and established connections) should get into our network.
So far we had no problems with this setup and it works perfectly.
Solution 3:
If there is no need for outside connectivity, then private networks can be used. That is the reason for defining private address space also in IPv6.
NAT is a hack that was invented to delay IPv4 address space exhaustion. NAT causes issues with applications, and to get the applications to work with NAT, more hacks are needed which conflict with the original design of IP.
So, the preferred way is to work like Yarik answered, use proper stateful firewall at the edge of the network.
Solution 4:
As stated, this is the way IP was designed to work, and it does work well. NAT introduces annoying problems at times. Some have described NAT's "hiding" of the internal IP as an advantage, but it can also be a disadvantage.
I worked in a place with a /16 and we used publicly routable IPv4 addresses on every device (including printers and mobile phones and electronic timeclocks). It worked just fine, and in addition it made tracking down misbehaving users and devices all that much easier. It also limited the impact of those users, so that if someone managed to start spreading malware or gets caught torrenting, it's less likely to affect (say) your mail servers' ability to communicate unhindered because of it being on a blacklist.
Solution 5:
The IPv6 proponets saw NAT as a temporary hack to alleviate IPv4 address exhaustion and hence NAT would not be needed with IPv6.
However NAT has a few advantages other than stopping address exhaustion.
- NAT decouples your internal addressing from your internet connectivity.
- At least on linux, NAT tends to fail-closed. If the iptables rules fail to load then devices with private IPs will have no connectivity to the internet, this will quickly be noticed and fixed. Packet inspection firewalls on the other hand can easilly fail open if IP forwarding is turned on but the iptables rules are not loaded.
- NAT hides which internal machine made a request. Privacy extensions help to some extent with this but they don't hide the subnet and they are a client-side feature so the client OS, not the network admin, chooses whether or not they are used.
As such I would expect at least some companies to chosee to deploy v6 with NAT in the same way they do for IPv4. Others may side with the IPv6 proponents and go for firewalls but no address translation.
I would strongly encourage you (and anyone else considering implementing NAT with IPv6) to reconsider, after reading RFC 4864 for advice on what to do instead of NAT
I have read it but I don't think it provides a complete reprelacement for NAT.
- NAT decouples your internal addressing from your internet connectivity.
The IPv6 propnents "soloution" to this is threefold, run multiple addresses in paralell, automate assignment of dynamic addresses from provider(s) to internal netwrks and use ULAs to provide long-term local addreses.
Running addresses of different lifetime in parallel runs the risk that non-permanent addresses will end up inadvertantly in long-term configuration. Running multiple internet addresses in paralell has the problem that client operating systems are not equipped to know which internet gateway their packets will leave from.
Prefix delegation has been solidly implemented for single-level scenarios where a single CPE router requests a prefix from the ISP and assigns it to one or more local interfaces but there doesn't currently seem to be a good implementation for multi-level delgation within a customer site.
- At least on linux, NAT tends to fail-closed. If the iptables rules fail to load then devices with private IPs will have no connectivity to the internet, this will quickly be noticed and fixed. Packet inspection firewalls on the other hand can easilly fail open if IP forwarding is turned on but the iptables rules are not loaded.
The IPv6 proponents doe not seem to provide any answer to this. They seem to simply assume that accidents will not happen.
- NAT hides which internal machine made a request.
Privacy extensions help to some extent with this but they don't hide the subnet and they are a client-side feature so the client OS, not the network admin, chooses whether or not they are used.
There is a proposal for assinging /128s to individual machines and then creating IGP entries to route them but i'm not aware of anyone actually implementing this in practice.