I Say ULA, You Hear NAT
Ed Horley wrote another great post arguing you don’t need Unique Local Addresses in an IPv6 network … and I couldn’t figure out what the problem was until I got the underlying context: it seems many engineers try to transplant their IPv4 mentality into IPv6 world and see ULAs as a nice replacement for RFC1918 with NAT66 or NPT66 on the private network edge. No wonder Ed argues against that.
While we still cannot escape the throes of NAT66/NPT66, you shouldn’t use ULAs as 1:1 RFC1918 replacement. Remember that every IPv6 host has more than one IPv6 address per interface. One of those addresses might be an ULA address (for intra-company communication), another one a public (PI or PA) IPv6 address (for global connectivity).
Using ULAs in combination with public IPv6 addresses is identical to the solutions Ed proposed in his blog post (see Figure 5 in his post), with a crucial difference: Ed’s solution requires you to modify IPv6 source address selection prefix policy entries, while ULA+global combination (usually) works with the default settings of most operating systems.
Need to Get Started with IPv6?
My IPv6 webinars should bring your IPv6 networking skills up to speed:
- Start with Introduction to IPv6 (or its service provider counterpart);
- Building Large IPv6 Networks will help you design and deploy your IPv6 core and access networks;
- IPv6 Security is a must-have and you’ll probably need some IPv6 transition mechanisms;
- Sick of endless transition steps? Jump straight into IPv6-only data centers.
If you need help in your IPv6 design or deployment, I’m just a WebEx call away.
many companies use NAT for traffic engineering purposes (especially customer/vendor extranets) and it's easier to NAT traffic to make it going the way you want than setting up PBR all over the place.
We all know about dark messy corners of the corporate networks, NAT may be the simplest solution to make things done (adding more mess though but that's another story, we need to get things done and may not have time to redesign existing infrastructure.
I am sure that customers will push vendors to implement NAT66 because they need/want it and it will be done regardless if IETF thinks it's ok or not.
In regards to Dmitriy's comments about application guys having to bind to specific IP's for internal. If the OS is following RFC 6724 then applications will benefit from being passed the correct information for source/destination selection and will get an ordered list. This problem is no different for IPv4 hosts that have multiple IPv4 addresses, there has to be some sort of logic to pick one verse the other. Someone has to make a decision about what IP address to bind to or just bind to them all and reserve a port instead. I disagree with his comments about NAT and PBR. I believe the current IPv4 solution puts many artificial restrictions on redundancy, path selection and artificially imposes restrictions on having to pass through stateful devices. IPv6 gives companies enough addresses but also network prefixes to not have to worry about NAT. This allows you to truly have global and universal firewall rules that are not concerned with things like did the source traffic come as RFC 1918 or the real IPv4 address etc.
Finally, I guess we also need to decide, is it NPT66 or NPTv6 - I was using the name from the RFC (http://tools.ietf.org/html/rfc6296) but I have seen you and several others say NPT66 instead. I guess I will update my post to tell folks you might see it referenced either way for now.
- Ed