On 26 dec 2007, at 22:40, Leo Bicknell wrote:
If you're a shop that uses such features today (MAC/Port tracking, DHCP snooping, etc) to "secure" your IPv4 infrastructure does IPv6 RA's represent a step backwards from a security perspective? Would IPv6 deployment be hindered until there is DHCPv6 snooping and DHCPv6 is able to provide a default gateway, a-la how it is done today in IPv4?
It would be very interesting to me if the answer was "it's moot because we're going to move to CGA's as a step forward"; it would be equally interesting if the answer is "CGA isn't ready for prime time / we can't deploy it for xyz reason, so IPv6 is less secure than IPv4 today and that's a problem."
With IPv4, a lot of these features are developed by vendors and (sometimes) later standardized in the IETF or elsewhere. With IPv6, the vendors haven't quite caught up with the IETF standardization efforts yet, so the situation is samewhat different. For instance, SEND/CGA is excellent work, but we've only recently seen the first implementations. Personally, I'm not a big fan of DHCPv6. First of all, from a philosophical standpoint: I believe that stateless autoconfiguration is a better model in most cases (although it obviously doesn't support 100% of the DHCP functionality). But apart from that, some of the choices made along the way make DHCPv6 a lot harder to use than DHCP for IPv4. Not only do you lack a default gateway (which is actually a good thing for fate sharing reasons) but also a subnet prefix length and any extra on-link prefixes. So even if you do address configuration with DHCPv6 you need RAs for that other information. There's also tons of ways to complicate your life by mixing stateless autoconf and DHCPv6, especially since most systems don't support DHCPv6 unless you install additional software. Last but not least, DHCPv6 has a stateful mode that's appropriate for address assignment or prefix delegation, and a stateless mode that's more efficient for the configuration of information that's not client-specific. Unfortunately, it's up to the client to initiate the desired mode. Then there are the M and O bits in RAs that tell you whether to do DHCPv6 but a number of DHCPv6 aficionados look like they want to ignore those bits. What this all boils down to is that if you want to deploy DHCPv6 you need to install software on a lot of systems and modify a lot of configurations. If you're going to do all that, it's easier to simply configure this stuff manually. The only downside to that is that it's not compatible with easy renumbering, but then, you need to do more than just automate address assignment to support easy renumbering. I don't think IPv6 address configuration in general and DHCPv6 in particular will ever be fully equivalent to how things work with IPv4. This is really the place where the differences between the two protocols are the biggest. For those of us who are familiar with IPX, AppleTalk, CLNP and IPv4: IPv6 basically uses the address configuration methods from all of those, no wonder it can get a bit complex. That being said, please go to your vendors and tell them what you need. Preferably at a high level, so they can provide the functionality in the optimal way, rather than just revert back to the IPv4 way of doing things.