On 4/17/14 4:45 PM, "George Herbert" <george.herbert@gmail.com> wrote:
There's a fair argument to be made which says that kind of NAT is
unhealthy. If its proponents are correct, they'll win that argument later on with NAT-incompatible technology that enterprises want. After all, enterprise security folk didn't want the Internet in the corporate network at all, but having a web browser on every desk is just too darn useful. Where they won't win that argument is in the stretch of maximum risk for the enterprise security folk.
Any technology has associated risks, it's a matter of how you reduce/mitigate them. This paranoia thingie about IPv6 is getting a bit old. Just because you don't (seem to) understand how it works, it doesn't mean no one else should use it.
You are missing the point.
Granted, anyone who is IPv6 aware doing a green-field enterprise firewall design today should probably choose another way than NAT.
What you are failing is that "redesign firewall rules and approach from scratch along with the IPv6 implementation" usually is not the chosen path, versus "re-implement the same v4 firewall rules and technologies in IPv6 for the IPv6 implementation", because all the IPv6 aware net admins are having too much to do dealing with all the other conversion issues, vendor readiness all across the stack, etc.
One of the things we (operator hat) like about IPv6 is that we get to clean up the mess we made in IPv4. In many cases we've significantly reduced the number of firewall rules or ACL lines, because we don't have disaggregate blocks we have to stack up. On my enterprise firewalls, I had a couple of DMZs, a couple of internal networks, and policies for what could get where. Firewalls referred to objects of various kinds, some of which had multiple addresses listed; putting servers with similar policies in a single /64 (or a /60 if I needed separate VLANs) would have simplified things. And the policy/rule difference between net 10 addresses internally and GUA prefixes internally is null. So, yeah, you have to give your firewall administrator time to walk through the rules and figure out what they ought to be in IPv6. Your firewall administrator has been wanting to clean up the rules for the last two years, anyway. Even if the above doesn't apply to you, what rules do you have that you can't copy? * deny ICMP to any. Can't do that. Must allow at least some messages. * deny (public address range) to (private address range) unless initiated form inside. Substitute external and internal prefixes. * deny (outside) to (DMZ) except (port ranges). Same in IPv6. * deny (inside) to (DMZ) except (port ranges). Same in IPv6. As I recall, the rules were in place even when we used NAT. If "no thinking required" firewall administration is your goal, I'm not clear how this interferes.
Variations on this theme are part of why it's 2014 and IPv6 hasn't already taken over the world. The more rabid IPv6 proponents have in fact shot the transition in the legs repeatedly, and those of us who have been on the front lines would like you all to please shut up and get out of the way so we can actually finish effecting v6 deployment and move on to mopping up things like NAT later.
This is why listening to operators is important.
Some operators want NAT. Some don't. There are loud voices on both sides. Consensus seems slightly against. However, ULA + NPT works. Lee