On Jul 15, 2011, at 6:31 AM, RJ Atkinson wrote: > I apologise for being unclear. The document I was trying to propose in the > quoted text above was NOT about protocol changes, but instead would focus on > extant mitigations -- so the document I was proposing would more obviously > seem to fit in IPv6 Ops WG.
Sounds reasonable to me. One general consideration in this note. In addition to the fact of multiple prefixes on a LAN, IPv6 Privacy Addresses (RFC 4491) are a case in which a single interface (and therefore MAC address) might legitimately have multiple addresses within the same prefix. Unless I am mistaken, Windows by default creates an address daily but keeps each such address active for a week, so any case in which Windows would use one IPv4 address, at any given time it will consider seven IPv6 addresses to be active. In addition, virtual machines in data centers amplify address use; one could imagine the address of a virtual machine serving a single user or service to be the counterpart of a locator+identifier in the sense that RFC 1992 uses the terms. So a part of the advice to implementers is to expect a much larger number of active addresses at any given time to be normal. There are of course ways to simplify that in implementation. In a host/router's neighbor tables, it would make sense to keep a "used" flag. At least for routers (which normally have most of the hosts in a subnet as neighbors most of the time), it is common to periodically ARP/ND each address unicast and cull the table if it fails to respond (rather than simply timing the address out). One could modify that slightly by setting a flag in the neighbor entry when a datagram is sent to the address, and on the periodic sweep culling addresses that were not used and refreshing addresses that have been used. There is also a place for LRU-style behavior. If the neighbor table is finite in size, keep an LRU list, moving used and new entries to the tail and simply overwriting entries from the front when needed. If there is no hard bound on the neighbor table besides the size of memory, one could imagine sweeping at a rate comparable to its size - every mumble time units culling/refreshing a percentage of the table. Where I worry is the concept of a hard limit on address count per MAC address, due to the existence of virtual hosts. Speaking as a vendor of the equipment we're concerned about here, I would rather provide an option that enables the administrator to buy more memory if that's what's needed than force him into a situation that might be suboptimal for his network. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
