The desire to protect individual privacy can conflict with the desire to effectively maintain and debug a network. Having clients use addresses that change over time will make it more difficult to track down and isolate operational problems. For example, when looking at packet traces, it could become more difficult to determine whether one is seeing behavior caused by a single errant host or a number of them.¶
It is currently recommended that network deployments provide multiple IPv6 addresses from each prefix to general-purpose hosts [RFC7934]. However, in some scenarios, use of a large number of IPv6 addresses may have negative implications on network devices that need to maintain entries for each IPv6 address in some data structures (e.g., SAVI [RFC7039]). For example, concurrent active use of multiple IPv6 addresses will increase Neighbor Discovery traffic if Neighbor Caches in network devices are not large enough to store all addresses on the link. This can impact performance and energy efficiency on networks on which multicast is expensive (see e.g., [MCAST-PROBLEMS]). Additionally, some network-security devices might incorrectly infer IPv6 address forging if temporary addresses are regenerated at a high rate.¶
The use of temporary addresses may cause unexpected difficulties with some applications. For example, some servers refuse to accept communications from clients for which they cannot map the IP address into a DNS name. That is, they perform a DNS PTR query to determine the DNS name corresponding to an IPv6 address, and may then also perform a AAAA query on the returned name to verify it maps back into the same address. Consequently, clients not properly registered in the DNS may be unable to access some services. However, a host's DNS name (if non-changing) would serve as a constant identifier. The wide deployment of the extension described in this document could challenge the practice of inverse-DNS-based "validation", which has little validity, though it is widely implemented. In order to meet server challenges, hosts could register temporary addresses in the DNS using random names (for example, a string version of the random address itself), albeit at the expense of increased complexity.¶
In addition, some applications may not behave robustly if an address becomes invalid while it is still in use by the application or if the application opens multiple sessions and expects them to all use the same address.¶
[RFC4941] employed a randomized temporary IID for generating a set of temporary addresses, such that temporary addresses configured at a given time for multiple SLAAC prefixes would employ the same IID. Sharing the same IID among multiple addresses allowed a host to join only one solicited-node multicast group per temporary address set.¶
This document requires that the IIDs of all temporary addresses on a host are statistically different from each other. This means that when a network employs multiple prefixes, each temporary address of a set will result in a different solicited-node multicast address, and, thus, the number of multicast groups that a host must join becomes a function of the number of SLAAC prefixes employed for generating temporary addresses.¶
Thus, a network that employs multiple prefixes may require hosts to join more multicast groups than in the case of implementations of RFC 4941. If the number of multicast groups were large enough, a host might need to resort to setting the network interface card to promiscuous mode. This could cause the host to process more packets than strictly necessary and might have a negative impact on battery life and system performance in general.¶
We note that since this document reduces the default TEMP_VALID_LIFETIME from 7 days (in [RFC4941]) to 2 days, the number of concurrent temporary addresses per SLAAC prefix will be smaller than for RFC 4941 implementations; thus, the number of multicast groups for a network that employs, say, between 1 and 3 prefixes, will be similar to the number of such groups for RFC 4941 implementations.¶
Implementations concerned with the maximum number of multicast groups that would be required to join as a result of configured addresses, or the overall number of configured addresses, should consider enforcing implementation-specific limits on, e.g., the maximum number of configured addresses, the maximum number of SLAAC prefixes that are employed for autoconfiguration, and/or the maximum ratio for TEMP_VALID_LIFETIME/TEMP_PREFERRED_LIFETIME (which ultimately controls the approximate number of concurrent temporary addresses per SLAAC prefix). Many of these configuration limits are readily available in SLAAC and RFC 4941 implementations. We note that these configurable limits are meant to prevent pathological behaviors (as opposed to simply limiting the usage of IPv6 addresses), since IPv6 implementations are expected to leverage the usage of multiple addresses [RFC7934].¶