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 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. 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. Saying it's simple and "redesign your network" makes most people turn away from IPv6 and hope that something better will come along. The future of IPv6 for most organizations will include: DHCPv6 for stateful address assignment. 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). 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). 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. Period. 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. 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. On Wed, Nov 30, 2011 at 11:39 AM, Jeff Wheeler <jsw@inconcepts.biz> wrote:
On Wed, Nov 30, 2011 at 9:48 AM, Ray Soucy <rps@maine.edu> wrote:
1. Using a stateful firewall (not an ACL) outside the router responsible for the 64-bit prefix. This doesn't scale, and is not a design many would find acceptable (it has almost all the problems of an ISP running NAT)
Owen has suggested "stateful firewall" as a solution to me in the past. There is not currently any firewall with the necessary features to do this. We sometimes knee-jerk and think "stateful firewall has gobs of memory and can spend more CPU time on each packet, so it is a more likely solution." In this case that does not matter. You can't have 2^64 bits of memory.
You could make a firewall with the needed features (or a layer-3 switch), but it would have to be the layer-3 gateway of the subnets you are protecting (not an upstream device) and it would need knowledge of all addresses in use on the subnet, which must fit within its ND table limits. Only DHCP snooping can do this and customers are not exactly keen on receiving DHCP-assigned addresses in mixed datacenter environments, even if the addresses are static ones. Once you do that, you need to limit the number of addresses that can be leased to each customer to far less than a /64 anyway. All you gain by having all that complexity is the appearance of bigger subnets, when in reality, they are non-functional except for the limited number of addresses which are actively leased out.
Again the arguments for /64 are not promising. It is much less complicated to simply deploy a longer subnet.
On Wed, Nov 30, 2011 at 11:13 AM, Jimmy Hess <mysidia@gmail.com> wrote:
On Wed, Nov 30, 2011 at 8:48 AM, Ray Soucy <rps@maine.edu> wrote:
Saying you can mitigate neighbor table exhaustion with a "simple ACL" is misleading (and you're not the only one who has tried to make that claim).
It's true, though, you can.
From a network design POV, there may still be reasons to prefer the ACL method. They better be good reasons, such as a requirement for SLAAC on a large LAN.
No, Jimmy, you can't do that with SLAAC. I do not think you understand the problem.
-- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/