Network Working Group R. Hinden Request for Comments: 4311 Nokia Updates: 2461 D. Thaler Category: Standards Track Microsoft November 2005IPv6 Host-to-Router Load Sharing
1. Introduction
In the conceptual sending algorithm in [ND] and in the optional extension in [ROUTERSEL], a next hop is chosen when no destination cache entry exists for an off-link destination or when communication through an existing router is failing. Normally, a router is selected the first time traffic is sent to a specific destination IP address. Subsequent traffic to the same destination address continues to use the same router unless there is some reason to change to a different router (e.g., a redirect message is received, or the router is found to be unreachable).
Hinden & Thaler Standards Track [Page 1]
RFC 4311 IPv6 Host-to-Router Load Sharing November 2005
It is often desirable when there is more than one equivalent router that hosts distribute their outgoing traffic among these routers. This shares the load among multiple routers and provides better performance for the host's traffic.
2. Load Sharing
When a host chooses from multiple equivalent routers, it SHOULD support choosing using some method that distributes load for different destinations among the equivalent routers rather than always choosing the same router (e.g., the first in the list). This memo takes no stance on whether the support for load sharing should be turned on or off by default. Furthermore, a host that does attempt to distribute load among routers SHOULD use a hash-based scheme that takes (at least) the destination IP address into account, such as those described in [MULTIPATH], for choosing a router to use. Note that traffic for a given destination address will use the same router as long as the Destination Cache Entry for the destination address is not deleted. With a hash-based scheme, traffic for a given destination address will use the same router over time even if the Destination Cache Entry is deleted, as long as the list of equivalent routers remains the same.
Hinden & Thaler Standards Track [Page 2]
RFC 4311 IPv6 Host-to-Router Load Sharing November 2005 3. Security ConsiderationsAs mentioned in [MULTIPATH], when next-hop selection is predictable, an application can synthesize traffic that will all hash the same, making it possible to launch a denial-of-service attack against the load-sharing algorithm, and overload a particular router. This can even be done by a remote application that can cause a host to respond to a given destination address. A special case of this is when the same (single) next-hop is always selected, such as in the algorithm allowed by [ND]. Introducing hashing can make such an attack more difficult; the more unpredictable the hash is, the harder it becomes to conduct a denial-of-service attack against any single router.
4. Acknowledgements
The authors of this document would like to thank Erik Nordmark, Brian Haberman, Steve Deering, Aron Silverton, Christian Huitema, and Pekka Savola.
Hinden & Thaler Standards Track [Page 3]
RFC 4311 IPv6 Host-to-Router Load Sharing November 2005 5. Normative References[ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
6. Informative References
[MULTIPATH] Thaler, D. and C. Hopps, "Multipath Issues in Unicast
Hinden & Thaler Standards Track [Page 4]
RFC 4311 IPv6 Host-to-Router Load Sharing November 2005
Full Copyright Statement
