draft-ietf-ipv6-host-load-sharing-03.txt | draft-ietf-ipv6-host-load-sharing-04.txt | |||
---|---|---|---|---|
IPv6 Working Group R. Hinden | IPv6 Working Group R. Hinden | |||
INTERNET-DRAFT Nokia | INTERNET-DRAFT Nokia | |||
October 18, 2004 D. Thaler | June 23, 2005 D. Thaler | |||
Expires April 2005 Microsoft | Expires December 2005 Microsoft | |||
IPv6 Host to Router Load Sharing | IPv6 Host to Router Load Sharing | |||
<draft-ietf-ipv6-host-load-sharing-03.txt> | <draft-ietf-ipv6-host-load-sharing-04.txt> | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, I certify that any applicable | By submitting this Internet-Draft, each author represents that any | |||
patent or other IPR claims of which I am aware have been | applicable patent or other IPR claims of which he or she is aware | |||
disclosed, or will be disclosed, and any of which I become aware | have been or will be disclosed, and any of which he or she becomes | |||
will be disclosed, in accordance with RFC 3668. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six | Internet-Drafts are draft documents valid for a maximum of six | |||
months and may be updated, replaced, or obsoleted by other | months and may be updated, replaced, or obsoleted by other | |||
documents at any time. It is inappropriate to use Internet-Drafts | documents at any time. It is inappropriate to use Internet-Drafts | |||
as reference material or to cite them other than as "work in | as reference material or to cite them other than as "work in | |||
progress." | progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
Copyright Notice | Copyright Notice | |||
Draft IPv6 Host to Router Load Sharing October 2004 | Draft IPv6 Host to Router Load Sharing June 2005 | |||
Copyright (C) The Internet Society (2004). All Rights Reserved. | Copyright (C) The Internet Society (2005). All Rights Reserved. | |||
Abstract | Abstract | |||
The original IPv6 conceptual sending algorithm does not do load- | The original IPv6 conceptual sending algorithm does not do load- | |||
sharing among equivalent IPv6 routers, and suggests schemes which | sharing among equivalent IPv6 routers, and suggests schemes which | |||
can be problematic in practice. This document updates the | can be problematic in practice. This document updates the | |||
conceptual sending algorithm so that traffic to different | conceptual sending algorithm in RFC 2461 so that traffic to | |||
destinations can be distributed among routers in an efficient | different destinations can be distributed among routers in an | |||
fashion. | efficient fashion. | |||
1. Introduction | 1. Introduction | |||
In the conceptual sending algorithm in [ND] and in the optional | In the conceptual sending algorithm in [ND] and in the optional | |||
extension in [ROUTERSEL], a next hop is chosen when no destination | extension in [ROUTERSEL], a next hop is chosen when no destination | |||
cache entry exists for an off-link destination or when | cache entry exists for an off-link destination or when | |||
communication through an existing router is failing. Normally a | communication through an existing router is failing. Normally a | |||
router is selected the first time traffic is sent to a specific | router is selected the first time traffic is sent to a specific | |||
destination IP address. Subsequent traffic to the same | destination IP address. Subsequent traffic to the same | |||
destination address continues to use the same router unless there | destination address continues to use the same router unless there | |||
skipping to change at page 2, line 40 | skipping to change at page 2, line 40 | |||
In addition, as described in [ADDRSEL], the choice of next hop may | In addition, as described in [ADDRSEL], the choice of next hop may | |||
also affect the choice of source address, and hence indirectly | also affect the choice of source address, and hence indirectly | |||
(and to a lesser extent) may affect the router used for inbound | (and to a lesser extent) may affect the router used for inbound | |||
traffic as well. | traffic as well. | |||
In both the base sending algorithm and in the optional extension, | In both the base sending algorithm and in the optional extension, | |||
sometimes a host has a choice of multiple equivalent routers for a | sometimes a host has a choice of multiple equivalent routers for a | |||
destination. That is, all other factors are equal and a host must | destination. That is, all other factors are equal and a host must | |||
break a tie via some implementation-specific means. | break a tie via some implementation-specific means. | |||
It is typically desirable when there is more than one equivalent | It is often desirable when there is more than one equivalent | |||
router that hosts distribute their outgoing traffic among these | router that hosts distribute their outgoing traffic among these | |||
routers. This shares the load among multiple routers and provides | routers. This shares the load among multiple routers and provides | |||
better performance for the host's traffic. | better performance for the host's traffic. | |||
On the other hand, load sharing can be undesirable in situations | On the other hand, load sharing can be undesirable in situations | |||
where sufficient capacity is available through a single router and | where sufficient capacity is available through a single router and | |||
the traffic patterns could be more predictable by using a single | the traffic patterns could be more predictable by using a single | |||
router; in particular, this helps to diagnose connectivity | router; in particular, this helps to diagnose connectivity | |||
problems beyond the first-hop routers. | problems beyond the first-hop routers. | |||
Draft IPv6 Host to Router Load Sharing October 2004 | Draft IPv6 Host to Router Load Sharing June 2005 | |||
[ND] does not require any particular behavior in this respect. It | [ND] does not require any particular behavior in this respect. It | |||
specifies that an implementation may always choose the same router | specifies that an implementation may always choose the same router | |||
(e.g., the first in the list) or may cycle through the routers in | (e.g., the first in the list) or may cycle through the routers in | |||
a round-robin manner. Both of these suggestions are problematic. | a round-robin manner. Both of these suggestions are problematic. | |||
Clearly, always choosing the same router does not provide load | Clearly, always choosing the same router does not provide load | |||
sharing. Some problems with load sharing using naive tie-breaking | sharing. Some problems with load sharing using naive tie-breaking | |||
techniques such as round-robin and random are discussed in | techniques such as round-robin and random are discussed in | |||
[MULTIPATH]. While the destination cache provides some stability | [MULTIPATH]. While the destination cache provides some stability | |||
skipping to change at page 3, line 37 | skipping to change at page 3, line 37 | |||
2. Load Sharing | 2. Load Sharing | |||
When a host chooses from multiple equivalent routers, it SHOULD | When a host chooses from multiple equivalent routers, it SHOULD | |||
support choosing using some method which distributes load for | support choosing using some method which distributes load for | |||
different destinations among the equivalent routers rather than | different destinations among the equivalent routers rather than | |||
always choosing the same router (e.g., the first in the list). | always choosing the same router (e.g., the first in the list). | |||
This memo takes no stance on whether the support for load sharing | This memo takes no stance on whether the support for load sharing | |||
should be turned on or off by default. Furthermore, a host that | should be turned on or off by default. Furthermore, a host that | |||
does attempt to distribute load among routers SHOULD use a hash- | does attempt to distribute load among routers SHOULD use a hash- | |||
based scheme which takes the destination IP address into account, | based scheme which takes (at least) the destination IP address | |||
such as those described in [MULTIPATH], for choosing a router to | into account, such as those described in [MULTIPATH], for choosing | |||
use. | a router to use. | |||
Note that traffic for a given destination address will use the | Note that traffic for a given destination address will use the | |||
same router as long as the Destination Cache Entry for the | same router as long as the Destination Cache Entry for the | |||
destination address is not deleted. With a hash-based scheme, | destination address is not deleted. With a hash-based scheme, | |||
traffic for a given destination address will use the same router | traffic for a given destination address will use the same router | |||
over time even if the Destination Cache Entry is deleted, as long | over time even if the Destination Cache Entry is deleted, as long | |||
as the list of equivalent routers remains the same. | as the list of equivalent routers remains the same. | |||
Draft IPv6 Host to Router Load Sharing October 2004 | Draft IPv6 Host to Router Load Sharing June 2005 | |||
3. Security Considerations | 3. Security Considerations | |||
As mentioned in [MULTIPATH], when next-hop selection is | As mentioned in [MULTIPATH], when next-hop selection is | |||
predictable, an application can synthesize traffic that will all | predictable, an application can synthesize traffic that will all | |||
hash the same, making it possible to launch a denial-of-service | hash the same, making it possible to launch a denial-of-service | |||
attack against the load sharing algorithm, and overload a | attack against the load sharing algorithm, and overload a | |||
particular router. This can even be done by a remote application | particular router. This can even be done by a remote application | |||
that can cause a host to respond to a given destination address. | 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 | A special case of this is when the same (single) next-hop is | |||
skipping to change at page 5, line 5 | skipping to change at page 5, line 5 | |||
for IP Version 6 (IPv6)", RFC 2461, December 1998. | for IP Version 6 (IPv6)", RFC 2461, December 1998. | |||
[RFC2119] | [RFC2119] | |||
Bradner, S., "Key words for use in RFCs to Indicate | Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", RFC 2119, BCP0014, March 1997. | Requirement Levels", RFC 2119, BCP0014, March 1997. | |||
[ADDRSEL] | [ADDRSEL] | |||
Draves, R., "Default Address Selection for Internet Protocol | Draves, R., "Default Address Selection for Internet Protocol | |||
version 6 (IPv6)", RFC 3484, February 2003. | version 6 (IPv6)", RFC 3484, February 2003. | |||
Draft IPv6 Host to Router Load Sharing October 2004 | Draft IPv6 Host to Router Load Sharing June 2005 | |||
[ROUTERSEL] | ||||
Draves, R. and D. Thaler, "Default Router Preferences and | ||||
More-Specific Routes", Work in progress, draft-ietf- | ||||
ipv6-router-selection-07.txt, January 2005. | ||||
7. Informative References | 7. Informative References | |||
[MULTIPATH] | [MULTIPATH] | |||
Thaler, D. and C. Hopps, "Multipath Issues in Unicast and | Thaler, D. and C. Hopps, "Multipath Issues in Unicast and | |||
Multicast Next-Hop Selection", RFC 2991, November 2000. | Multicast Next-Hop Selection", RFC 2991, November 2000. | |||
[ROUTERSEL] | ||||
Draves, R. and D. Thaler, "Default Router Preferences and | ||||
More-Specific Routes", Work in progress, draft-ietf- | ||||
ipv6-router-selection-03.txt, December 2003. | ||||
8. Authors' Addresses | 8. Authors' Addresses | |||
Robert Hinden | Robert Hinden | |||
Nokia | Nokia | |||
313 Fairchild Drive | 313 Fairchild Drive | |||
Mountain View, CA 94043 | Mountain View, CA 94043 | |||
Phone: +1 650 625-2004 | Phone: +1 650 625-2004 | |||
Email: bob.hinden@nokia.com | Email: bob.hinden@nokia.com | |||
Dave Thaler | Dave Thaler | |||
Microsoft Corporation | Microsoft Corporation | |||
One Microsoft Way | One Microsoft Way | |||
Redmond, WA 98052 | Redmond, WA 98052 | |||
Phone: +1 425 703 8835 | Phone: +1 425 703 8835 | |||
EMail: dthaler@microsoft.com | EMail: dthaler@microsoft.com | |||
9. Full Copyright Statement | 9. Full Copyright Statement | |||
Copyright (C) The Internet Society (2004). This document is | Copyright (C) The Internet Society (2005). This document is | |||
subject to the rights, licenses and restrictions contained in BCP | subject to the rights, licenses and restrictions contained in BCP | |||
78, and except as set forth therein, the authors retain all their | 78, and except as set forth therein, the authors retain all their | |||
rights. | rights. | |||
This document and the information contained herein are provided on | This document and the information contained herein are provided on | |||
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | |||
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND | REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND | |||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, | |||
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT | EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT | |||
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR | THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR | |||
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A | ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A | |||
PARTICULAR PURPOSE. | PARTICULAR PURPOSE. | |||
Draft IPv6 Host to Router Load Sharing October 2004 | Draft IPv6 Host to Router Load Sharing June 2005 | |||
10. Intellectual Property | 10. Intellectual Property | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed | Intellectual Property Rights or other rights that might be claimed | |||
to pertain to the implementation or use of the technology | to pertain to the implementation or use of the technology | |||
described in this document or the extent to which any license | described in this document or the extent to which any license | |||
under such rights might or might not be available; nor does it | under such rights might or might not be available; nor does it | |||
represent that it has made any independent effort to identify any | represent that it has made any independent effort to identify any | |||
such rights. Information on the procedures with respect to rights | such rights. Information on the procedures with respect to rights | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |