(Response inline). On Thu, Oct 21, 2010 at 9:01 PM, Owen DeLong <owen@delong.com> wrote:
We've decided to disable SLAAC (State-Less Address Auto-Configuration) on almost all our IPv6 networks and use DHCPv6 exclusively. This
Ouch... Sounds painful.
Really? I don't know. Maybe as a consultant you don't see it, but I can't run a non-trivial network without having control over which hosts get an IPv6 address (and knowing which address they get) without creating a lot more work running around putting out fires. From a "buy-in" standpoint, SLAAC was a non-starter, giving people an option where they could enable IPv6 on a host-by-host basis ended up being the quickest path to adoption without IPv6 getting a black eye because of a security issue that couldn't be quickly dealt with, or older systems (RHEL 3 comes to mind) having an IPv6 bug triggered and crashing. IPAM is a critical component of IPv6 for any non-trivial deployment IMHO, I know Apple disagrees, but OK.
allows us to only respond with DHCPv6 to the hosts we want to get an IPv6 address instead of enabling it network-wide and crossing your fingers. The disadvantage here is that DHCPv6 client support is still limited (OS X has none for example). The argument is that IPv6 isn't mission critical yet, so we're waiting to see if vendors will come around and include DHCPv6 client support in the future.
It also means that you are even more subject to the issues of rogue RA and RA Spoofing.
How so? We still have RA (with a high priority) that's the only way DHCPv6 works. I guess there is a lot of misunderstanding about how DHCPv6 works, even among the experts...
Another thing you want to do is block rogue RA. RA-Guard is the feature name, but nobody has a working implementation yet. If you have switches that can do port-based access-lists with IPv6 you can create ingress filters to block out incoming RA on a per-port basis which is what we have done.
You must have a really hostile user base. I agree RA-Guard is a good idea and it does work on some switches. Where it is most glaringly lacking is in Wireless configurations, meaning that having a real RA is actually a limited measure of protection vs. having no RA.
Again, it sounds like you think DHCPv6 means no RA? This is not the case. I consider filtering RA (accidental or malicious) critical for any network, regardless of whether IPv6 is deployed or not. Just above you were complaining about me having problems with rogue RA... Now you're saying I'm being paranoid? I know you work for HE and everything, but really? If you don't block RA, you can get mis-configured hosts (Windows ICS comes to mind) hijacking traffic without even knowing about it on networks that you don't have IPv6 deployed on. That's the accidental side, though. On the malicious side, I consider IPv6 one of todays most effective attack vectors. I can easily jump on a network that doesn't even monitor IPv6, declare myself as a router, advertise myself as IPv6 DNS, and proxy all traffic on a network, often without setting off alarms. Remember, hosts by default usually have IPv6 enabled, and usually prefer IPv6 over IP. In the case of servers, most administrators who are diligent about making sure host-based firewalls are in place completely forget about IPv6, because they haven't deployed it yet. Just because you haven't deployed IPv6 doesn't mean it's not running on your network. This is especially true in an academic setting where people bring their own computers on to your network. Not filtering rogue RA seems a little insane, IMHO. I'm still shocked that RA-Guard hasn't become the default in modern switching... but if you don't think it's a problem, that works too. What are the odds that there will be a virus, worm, or tojan that decides to turn infected hosts into IPv6 routers, anyway... I really don't buy the argument that "advertising IPv6 yourself with a high priority will mitigate the impact of rogue RA". As mentioned, DHCPv6 still requires RA to work... by design, so your point is moot. But regardless, that mindset only protects against accidental rogue RA, not malicious RA, which is a significant security threat and _should_ be filtered as a best practice when possible. I would go as far as to argue it's worth pushing up switch upgrades to make sure you have hardware capable of doing so, but maybe I am just being paranoid. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/