On Nov 30, 2011, at 9:10 AM, Ray Soucy wrote:
Owen and I have gone back and fourth over the year(s) as well.
I think it really comes down to Owen's adamant belief that _every_ network should be a 64-bit prefix, and that SLAAC should be used for addressing, because it's simple and people will only adopt IPv6 if it's simple. The whole neighbor table exhaustion problem undermines that case he's trying to make, so he tries to dismiss it as a non-issue. It's nothing specific to Owen, it's basic human behavior.
I've never said SLAAC should be used for addressing. I have said that SLAAC is useful in many situations and can be a good tool. I have consistently said that administrators should be free to choose the addressing mechanism that work best for their environments. I do believe that there is no benefit to longer prefixes than /64. Nobody has provided any convincing evidence to the contrary. There are better ways to mitigate ND than longer prefixes.
I've always held the view that telling people IPv6 is simple is a lie and harmful to IPv6 adoption for a few reasons:
If people think IPv6 is simple, they don't bother investing time to plan out adoption and a phased deployment; they assume that when they need it they can just turn it on.
I don't believe I've said IPv6 is simple. I've said that IPv6 is easier than IPv4. It is. You don't have to worry about many of the common difficulties with IPv4 (NAT, address conservation, subnet rightsizing, etc.).
If IPv6 isn't at least as flexible as IPv4, and can't fit in the same operational model used for IPv4 today; then it will never be adopted.
I would argue that IPv6 is more flexible than IPv4, but, it does require changes to some IPv4 operational models. IP didn't fit the same operational model as IPX, yet we made the transition from IPX to IPv4, so, I don't buy into your idea that it won't be adopted if it doesn't fit the same operational models. Some operational models for IPv4 are obsoleted by IPv6. Such is the nature of protocol change.
Saying it's simple and "redesign your network" makes most people turn away from IPv6 and hope that something better will come along.
I wouldn't say redesign your network so much as design your IPv6 network. In some cases, keeping in mind your IPv4 topology is useful. In some cases, moving beyond the limitations under which your IPv4 topology was constructed is very beneficial in IPv6. For example, common scenario in enterprise IPv4 is a single link with half a dozen or so /28s on it as the server farm grew. There's no reason not to make that a single IPv6 /64 while still leaving all those different IPv4 networks in place. There's no benefit whatsoever to allocating half a dozen IPv6 prefixes or sizing them to some /120 or whatever.
The future of IPv6 for most organizations will include:
DHCPv6 for stateful address assignment.
I've never argued against DHCP usage.
NPT (Network Prefix Translation) and ULA address space internally (not NAT, but operationally identical); with load balancing between public allocations much like "dual WAN" SMB firewalls available for IPv4 (after all, having every SMB in the BGP table is not something that any of us want to see).
I'm not as convinced as you are of this.
Eventual use of NAT-PT and ALG for providing access to the legacy IPv4 Internet without having to operate a dual-stack network internally (once there is enough IPv6-enabled content so that you're only breaking some things by doing so).
Remains to be seen whether it will be NAT-PT, NAT64, NAT444, IVI, or something else for this. I'm not convinced that the enterprise will be where IPv4 is deprecated first. In fact, I suspect it is likely to be one of the last places to move from dual-stack to IPv6-only as you describe.
We won't see widespread adoption of IPv6 until we have a product people can buy in appliance form that can do these things, along with providing the typical functionality of an SMB firewall.
Time will tell. I suspect that if no such product is made available, it will not prevent widespread deployment of IPv6.
It seems a little silly that we're still having arguments about using 64-bit prefix lengths instead of focusing on how to move IPv6 to a position where it can be operationally identical to the way networks are run today and then promote adoption.
Some of us don't want to do that kind of damage to IPv6. As such, I prefer to deploy IPv6 as it is today and resolve the bugs and the security issues along the way (much like we did with IPv4). IPv6 can be operationally similar, but, making it operationally identical would take away many of its benefits.
You just can't tell people to turn on IPv6, ignore the security concerns, ignore the operational differences, and suck it up and forklift their network. It's not going to happen.
I've never said forklift your network or ignore the operational differences. In fact, I've said embrace the operational differences and celebrate the fact that you don't have to deal with NAT any more. Enjoy simplified address planning with massive headroom. I haven't said that security issues should be ignored, either. Just that they should be viewed in a proper context and assessed with a realistic evaluation of the magnitude of the risk and the difficulty of mitigation. The magnitude of risk is defined in terms of the probability of an event combined with the damage caused by such an event. What has also been lost here is that my description of the various mitigation tactics for ND exhaustion attacks depends on the type of network being protected. Strategies that work for point-to-point links (simple ACLs at the borders in most environments, for example) are not the same as strategies that work to protect client LANs (stateful firewalls with default deny inbound) or strategies necessary to protect server LANs (slightly more complex ACLs and other tactics). Owen