On Sun, 17 Jul 2011 21:53:20 +0930 Mark Smith <[email protected]> wrote:
> On Sun, 17 Jul 2011 13:54:06 +0200 > Sander Steffann <[email protected]> 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. > Actually, that level of change might not be that necessary. If the destination address for the Duplicate Address Detection probes was changed to the all-nodes rather than the solicited nodes multicast address, then all receving nodes could immediately create a neighbor cache entry for the new device if one doesn't already exist. From that point on, Neighbor Unreachability Detection would then take care of maintaining the neighbor cache entry, and deleting it if the host disappears. > > - 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 > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
