Hi,
There have been a few discussions on a few operational mailing lists in the last few weeks about the use of longer than /64s on point-to-point links. One valid reason to do so is to mitigate a Neighbor Discovery DoS, initiated by off-link sources sending traffic to incrementing destinations, causing the on-link router to issue large numbers of Neighbor Solicitations towards Solicited-Node multicast destinations for nodes that don't exist. RFC3756 described this vulnerability in section 4.3.2, "Neighbor Discovery DoS Attack". This issue isn't specific to point-to-point links. Any /64 is vulnerable. People who're advocating longer than /64s for point-to-point links as a mitigation for this issue can also advocate using prefix lengths longer than /64 for all IPv6 subnets. As I'm an advocate for the simplicity of using /64s for all links, I've been thinking how this issue could be avoided, without having to resort to longer than /64s, or other manual methods such as traffic filtering ACLs or static neighbor discovery entries. At the end of the description of the issue, RFC3756 mentions "This attack does not directly involve the trust models presented. However, if access to the link is restricted to registered nodes, and the access router keeps track of nodes that have registered for access on the link, the attack may be trivially plugged. However, no such mechanisms are currently standardized." I think Multicast Listener Discovery announcements for hosts' memberships of the Solicited Node multicast addresses could be used as this "membership registration" mechanism. When a router is asked to issue a neighbor solicitation for a downstream host, after it converts the destination address into a Solicited Node multicast address, is could then validate that multicast address against a list of known Solicited Node multicast addresses it has learned from the hosts via their MLD announcements. Neighbor Solications for Solicited Node multicast addresses that aren't known would be dropped, preventing off-link nodes from exhausting the router's neighbor discovery resources. Do people think using MLD announcements in this way would be suitable way to mitigate this DoS while preserving the simplicity of universal /64s? Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------