On Fri, Jan 3, 2014 at 10:24 AM, Doug Barton <dougb@dougbarton.us> wrote:
... and yet most IPv4 networks are not "completely unprotected."
We are apparently talking about "completely unprotected" networks here. Otherwise there is simply no problem. You would be filtering RA and many other things, because that is best practice and required by many security standards besides.
... which is simple to accomplish with a DOS, even if the clients implement the protocol correctly.
If we are on an unprotected network and we have evil intend, all is lost. The hacker can simply steal the traffic with a simple arp ping or a ton of other methods. The original claim was not evil intend, but that of an accident. But it still requires three mistakes: bad clients, bad routers and bad configuration.
That is the behavior specified in the RFC. Actual implementations might do
something different, but that is hardly the fault of the protocol designer. Have anyone here actually tested this, or are we just making up stuff?
It's been demonstrated several times at various venues, including at least 1 IETF meeting.
Doesn't work when I try it. The clients just keep using the old gateway and prefix. But I can't rule out there are bad clients out there, just that it does not happen on my network. Can you give any examples of bad clients?
Another person claimed that there would be 15 minuttes or more until the
network was fixed, after removing a rogue router. That too is completely wrong. Every client will monitor the currently used router. If it stops responding for 30 seconds, the clients will switch to an alternative router.
Again, you're assuming that the clients implement correctly, however I think this one is more common than not since this behavior has been prescribed long enough now.
This one is something that all major clients have correctly by now. It is a rather common use case for IPv6 after all. The user connects two gateways to his network and gets carefree automatic failover with a 30 seconds timer to detect failure. May not be good enough for your enterprise network, but sure is quite useful in the SOHO environment. And you still haven't provided an argument about why the default route
should not be added to DHCPv6.
I was not arguing that it didn't. Just that the perceived problem is not real. However, I might be inclined to believe that default route in DHCPv6 is a bad idea. It is a confusing concept, since we already no less than three methods (*) to discover default route and you want to add a fourth. This would be something that needs to be implemented in every client, and thus will not really be usable for at least a decade. By then everyone are used to RA. If you did add default route to DHCPv6, what is then supposed to happen to the other routes, that the client might discover? By the arguments in this thread, you do not really want default route from RA, but instead some security mechanism, that would prevent the client from obtaining routes and prefixes in addition to the one you provided. That seems to be a completely different issue. (*) prefix::, fe80:: and the one you get from RA. Regards, Baldur