On Sun, 17 Jul 2011 13:54:06 +0200 Sander Steffann <san...@steffann.nl> wrote:
> Hi, > > > I think the same applies to hosts with lots of VMs: maintaining a > > potentially > > large number of NC entries for a single MAC address is unlikely to scale. > > This is what routing is designed for. > > Then why are there 64 bits in the IID? And I don't think it has anything to > do with the MAC address. 1000 IPv6 addresses on 10 MAC addresses scales as > well as 1000 IPv6 addresses on 1000 MAC addresses. It might make a difference > for the switch, but not for ND/NC. > As people have observed, this is also a problem with IPv4 and ARP with a large enough subnet, so it isn't unique to IPv6, it's just that the size of IPv6 subnets is large and therefore it becomes more of an issue. I think the ultimate root cause is that the creation of neighbor cache entries is triggered by data plane traffic, rather than created by a control plane protocol i.e. a neighbor registration protocol. I think that means that what ever mitigations are put in place, they'll likely always be fundamentally vulnerable to data plane traffic attacks. If changing the way ND NS/NAs work is an option, then it might be better to adopt or use as a model the 6lowpan neighbor registration protocols, or perhaps review the ES-IS protocol as a model. That is obviously a large and wholesale change, however I think it would be the only way to truly eliminate any data plane traffic attacks on neighbor resolution. > - Sander > PS: I consider having the possibility of having a large amount of IPv6 > addresses on one interface a great feature, not something I would want to > limit. > Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
