draft-ietf-ipv6-host-load-sharing-02.txt | draft-ietf-ipv6-host-load-sharing-03.txt | |||
---|---|---|---|---|
IPv6 Working Group R. Hinden | IPv6 Working Group R. Hinden | |||
INTERNET-DRAFT Nokia | INTERNET-DRAFT Nokia | |||
May 4, 2004 D. Thaler | October 18, 2004 D. Thaler | |||
Expires November 2004 Microsoft | Expires April 2005 Microsoft | |||
IPv6 Host to Router Load Sharing | IPv6 Host to Router Load Sharing | |||
<draft-ietf-ipv6-host-load-sharing-02.txt> | <draft-ietf-ipv6-host-load-sharing-03.txt> | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with | By submitting this Internet-Draft, I certify that any applicable | |||
all provisions of Section 10 of RFC2026. | patent or other IPR claims of which I am aware have been | |||
disclosed, or will be disclosed, and any of which I become aware | ||||
will be disclosed, in accordance with RFC 3668. | ||||
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- | documents at any time. It is inappropriate to use Internet-Drafts | |||
Drafts as reference material or to cite them other than as "work | as reference material or to cite them other than as "work in | |||
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 | |||
Copyright (C) The Internet Society (2004). All Rights Reserved. | Draft IPv6 Host to Router Load Sharing October 2004 | |||
Draft IPv6 Host to Router Load Sharing May 2004 | Copyright (C) The Internet Society (2004). 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 so that traffic to different | |||
destinations can be distributed among routers in an efficient | destinations can be distributed among routers in an efficient | |||
fashion. | fashion. | |||
skipping to change at page 2, line 28 | skipping to change at page 2, line 30 | |||
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 | |||
is some reason to change to a different router (e.g., a redirect | is some reason to change to a different router (e.g., a redirect | |||
message is received, or the router is found to be unreachable). | message is received, or the router is found to be unreachable). | |||
In both the base algorithm and in the optional extension, | In addition, as described in [ADDRSEL], the choice of next hop may | |||
also affect the choice of source address, and hence indirectly | ||||
(and to a lesser extent) may affect the router used for inbound | ||||
traffic as well. | ||||
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 typically 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 | ||||
where sufficient capacity is available through a single router and | ||||
the traffic patterns could be more predictable by using a single | ||||
router; in particular, this helps to diagnose connectivity | ||||
problems beyond the first-hop routers. | ||||
Draft IPv6 Host to Router Load Sharing October 2004 | ||||
[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 | |||
since the determination is not per-packet, cache evictions or | since the determination is not per-packet, cache evictions or | |||
timeouts can still result in unstable or unpredictable paths over | timeouts can still result in unstable or unpredictable paths over | |||
time, lowering the performance and making it harder to diagnose | time, lowering the performance and making it harder to diagnose | |||
problems. Round-robin selection may also result in | problems. Round-robin selection may also result in | |||
Draft IPv6 Host to Router Load Sharing May 2004 | ||||
synchronization issues among hosts, where in the worst case the | synchronization issues among hosts, where in the worst case the | |||
load is concentrated on one router at a time. | load is concentrated on one router at a time. | |||
In the remainder of this document, the key words "MUST", "MUST | In the remainder of this document, the key words "MUST", "MUST | |||
NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", | NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", | |||
"RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as | "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as | |||
described in [RFC2119]. | described in [RFC2119]. | |||
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). | |||
Furthermore, a host that does attempt to distribute load among | This memo takes no stance on whether the support for load sharing | |||
routers SHOULD use a hash-based scheme, such as those described in | should be turned on or off by default. Furthermore, a host that | |||
[MULTIPATH], which takes the destination IP address into account. | does attempt to distribute load among routers SHOULD use a hash- | |||
based scheme which takes 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 | 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. | |||
3. Acknowledgments | Draft IPv6 Host to Router Load Sharing October 2004 | |||
The authors of this document would like to thank Erik Nordmark, | ||||
Brian Haberman, Steve Deering, Aron Silverton, and Christian | ||||
Huitema. | ||||
4. 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 | |||
always selected, such as in the algorithm allowed by [ND]. | always selected, such as in the algorithm allowed by [ND]. | |||
Introducing hashing can make such an attack more difficult; the | Introducing hashing can make such an attack more difficult; the | |||
Draft IPv6 Host to Router Load Sharing May 2004 | ||||
more unpredictable the hash is, the harder it becomes to conduct a | more unpredictable the hash is, the harder it becomes to conduct a | |||
denial-of-service attack against any single router. | denial-of-service attack against any single router. | |||
5. Normative References | However, a malicious local application can bypass the algorithm | |||
for its own traffic by using mechanisms such as raw sockets, and | ||||
remote attackers can still overload the routers directly. Hence, | ||||
the mechanisms discussed herein have no significant incremental | ||||
impact on Internet infrastructure security. | ||||
4. IANA Considerations | ||||
This document has no actions for IANA. | ||||
5. Acknowledgments | ||||
The authors of this document would like to thank Erik Nordmark, | ||||
Brian Haberman, Steve Deering, Aron Silverton, Christian Huitema, | ||||
and Pekka Savola. | ||||
6. Normative References | ||||
[ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery | [ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery | |||
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. | |||
6. Informative References | [ADDRSEL] | |||
Draves, R., "Default Address Selection for Internet Protocol | ||||
version 6 (IPv6)", RFC 3484, February 2003. | ||||
Draft IPv6 Host to Router Load Sharing October 2004 | ||||
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] | [ROUTERSEL] | |||
Draves, R. and D. Thaler, "Default Router Preferences and | Draves, R. and D. Thaler, "Default Router Preferences and | |||
More-Specific Routes", Work in progress, draft-ietf- | More-Specific Routes", Work in progress, draft-ietf- | |||
ipv6-router-selection-03.txt, December 2003. | ipv6-router-selection-03.txt, December 2003. | |||
7. 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 | |||
Draft IPv6 Host to Router Load Sharing May 2004 | ||||
8. Revision History | ||||
(This section to be removed before publication as an RFC) | ||||
Changes from draft-ietf-ipv6-load-sharing-01.txt: | ||||
o Changed load sharing from a MUST to a SHOULD. | ||||
o Added standard IETF intellectual property notice. | ||||
Changes from draft-ietf-ipv6-router-selection-02.txt: | ||||
o Split load sharing back into its own document. | ||||
o Made hash-based, rather than random, the rule. | ||||
9. Full Copyright Statement | 9. Full Copyright Statement | |||
Copyright (C) The Internet Society (2004). All Rights Reserved. | Copyright (C) The Internet Society (2004). This document is | |||
subject to the rights, licenses and restrictions contained in BCP | ||||
This document and translations of it may be copied and furnished | 78, and except as set forth therein, the authors retain all their | |||
to others, and derivative works that comment on or otherwise | rights. | |||
explain it or assist in its implmentation may be prepared, copied, | ||||
published and distributed, in whole or in part, without | ||||
restriction of any kind, provided that the above copyright notice | ||||
and this paragraph are included on all such copies and derivative | ||||
works. However, this document itself may not be modified in any | ||||
way, such as by removing the copyright notice or references to the | ||||
Internet Society or other Internet organizations, except as needed | ||||
for the purpose of developing Internet standards in which case the | ||||
procedures for copyrights defined in the Internet Standards | ||||
process must be followed, or as required to translate it into | ||||
languages other than English. | ||||
The limited permissions granted above are perpetual and will not | ||||
be revoked by the Internet Society or its successors or assigns. | ||||
This document and the information contained herein is provided on | This document and the information contained herein are provided on | |||
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET | an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | |||
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR | REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND | |||
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, | |||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT | |||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR | |||
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A | ||||
PARTICULAR PURPOSE. | ||||
Draft IPv6 Host to Router Load Sharing May 2004 | Draft IPv6 Host to Router Load Sharing October 2004 | |||
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.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |