On Sun, 18 Oct 2009, Mark Smith wrote:
On Sun, 18 Oct 2009 09:03:12 +0100 Andy Davidson <andy@nosignal.org> wrote:
On 18 Oct 2009, at 01:55, Ray Soucy wrote:
The only solution that lets us expand our roll out IPv6 to the edge without major changes to the production IPv4 network seems to point to making use of DHCPv6, so the effort has been focused there. [...] Needless to say, the thought of being able to enable IPv6 on a per- host basis is met with far less resistance than opening up the floodgates and letting SLAAC take control.
Hi, Roy --
Good summary, thanks for the write-up.
I reluctantly just use SLAAC on our own office LANs because, we're still quite a small and nimble team, therefore we can secure our network against our SLAAC security concerns by locking down access to the network. I realise this isn't going to work for everyone, as it doesn't fit well for the security needs of your much larger campus network. It also doesn't work for some of our customers who have DHCP in their toolbox for provision certain hosting environments.
DHCPv6 today lacks default-router option support, so you are left with some pretty awful choices if you don't want to use the router solicitation/advertisement, err, 'features' in SLAAC :
I'm curious what the issue is with not having a default-router option in DHCPv6?
There is a draft: http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00 Implementation is not there yet....
If it's because somebody could start up a rogue router and announce RAs, I think a rogue DHCPv6 server is (or will be) just as much a threat, if not more of one - I think it's more likely server OSes will include DHCPv6 servers than RA "servers".
Identified problems and hopefully published RFCs soon about the problem and possible fixes: http://tools.ietf.org/wg/v6ops/draft-ietf-v6ops-rogue-ra/ http://tools.ietf.org/wg/v6ops/draft-ietf-v6ops-ra-guard/ Best Regards, Janos Mohacsi