In your letter dated Fri, 15 Jul 2011 09:31:12 -0400 you wrote: >To some extent, I would prefer an approach where IPv6 Ops would work >on that informational document (threats/concerns, operational use cases, >existing mitigations that could be deployed) first. Then, if there >were use cases not adequately covered by the material in that (proposed) >IPv6 Ops WG document, the IPv6 WG could use that IPv6 Ops WG document >to examine potential protocol specification changes on a much more >informed basis.
I could be wrong, but the impression I got from the various ops lists is that the way you deal with this attack is to avoid using RFC-4862 and/or RFC-4861. For example: - Just use link local on a link between two routers - Configure a much longer prefix (/120) - Have /128s on separate interfaces - Use a static neighbor cache and then disable ND - (From draft-gashinsky-v6nd-enhance) Have hosts inject /128s And there is also - Use a statefull firewall (and break end-to-end connectivity). draft-gashinsky-v6nd-enhance give a nice overview, but more importantly already tries to modify RFC-4861. If v6ops first wants to spend time writing a requirements document, then that's fine with me. But to me it seems more productive to explore the design space, write an informational document about that and then solicit feedback from v6ops on whether there are any options that seem to make some kind of sense in their environment. >Operator input on this topic would be strongly >beneficial since this is fundamentally an operations issue. I would classify a protocol that is at the heart of IPv6 and that is subject of a relatively low-tech DoS as a protocol problem and not as an ops problem. (Of course, it remains an ops problem until the protocol is fixed) -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
