idnits 2.17.1 draft-ietf-ipv6-host-load-sharing-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 212. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 225. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 232. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 238. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 203), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2461 (ref. 'ND') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3484 (ref. 'ADDRSEL') (Obsoleted by RFC 6724) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Working Group R. Hinden 3 INTERNET-DRAFT Nokia 4 June 23, 2005 D. Thaler 5 Expires December 2005 Microsoft 7 IPv6 Host to Router Load Sharing 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 35 Draft IPv6 Host to Router Load Sharing June 2005 37 Copyright (C) The Internet Society (2005). All Rights Reserved. 39 Abstract 41 The original IPv6 conceptual sending algorithm does not do load- 42 sharing among equivalent IPv6 routers, and suggests schemes which 43 can be problematic in practice. This document updates the 44 conceptual sending algorithm in RFC 2461 so that traffic to 45 different destinations can be distributed among routers in an 46 efficient fashion. 48 1. Introduction 50 In the conceptual sending algorithm in [ND] and in the optional 51 extension in [ROUTERSEL], a next hop is chosen when no destination 52 cache entry exists for an off-link destination or when 53 communication through an existing router is failing. Normally a 54 router is selected the first time traffic is sent to a specific 55 destination IP address. Subsequent traffic to the same 56 destination address continues to use the same router unless there 57 is some reason to change to a different router (e.g., a redirect 58 message is received, or the router is found to be unreachable). 60 In addition, as described in [ADDRSEL], the choice of next hop may 61 also affect the choice of source address, and hence indirectly 62 (and to a lesser extent) may affect the router used for inbound 63 traffic as well. 65 In both the base sending algorithm and in the optional extension, 66 sometimes a host has a choice of multiple equivalent routers for a 67 destination. That is, all other factors are equal and a host must 68 break a tie via some implementation-specific means. 70 It is often desirable when there is more than one equivalent 71 router that hosts distribute their outgoing traffic among these 72 routers. This shares the load among multiple routers and provides 73 better performance for the host's traffic. 75 On the other hand, load sharing can be undesirable in situations 76 where sufficient capacity is available through a single router and 77 the traffic patterns could be more predictable by using a single 78 router; in particular, this helps to diagnose connectivity 79 problems beyond the first-hop routers. 81 Draft IPv6 Host to Router Load Sharing June 2005 83 [ND] does not require any particular behavior in this respect. It 84 specifies that an implementation may always choose the same router 85 (e.g., the first in the list) or may cycle through the routers in 86 a round-robin manner. Both of these suggestions are problematic. 88 Clearly, always choosing the same router does not provide load 89 sharing. Some problems with load sharing using naive tie-breaking 90 techniques such as round-robin and random are discussed in 91 [MULTIPATH]. While the destination cache provides some stability 92 since the determination is not per-packet, cache evictions or 93 timeouts can still result in unstable or unpredictable paths over 94 time, lowering the performance and making it harder to diagnose 95 problems. Round-robin selection may also result in 96 synchronization issues among hosts, where in the worst case the 97 load is concentrated on one router at a time. 99 In the remainder of this document, the key words "MUST", "MUST 100 NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 101 "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 102 described in [RFC2119]. 104 2. Load Sharing 106 When a host chooses from multiple equivalent routers, it SHOULD 107 support choosing using some method which distributes load for 108 different destinations among the equivalent routers rather than 109 always choosing the same router (e.g., the first in the list). 110 This memo takes no stance on whether the support for load sharing 111 should be turned on or off by default. Furthermore, a host that 112 does attempt to distribute load among routers SHOULD use a hash- 113 based scheme which takes (at least) the destination IP address 114 into account, such as those described in [MULTIPATH], for choosing 115 a router to use. 117 Note that traffic for a given destination address will use the 118 same router as long as the Destination Cache Entry for the 119 destination address is not deleted. With a hash-based scheme, 120 traffic for a given destination address will use the same router 121 over time even if the Destination Cache Entry is deleted, as long 122 as the list of equivalent routers remains the same. 124 Draft IPv6 Host to Router Load Sharing June 2005 126 3. Security Considerations 128 As mentioned in [MULTIPATH], when next-hop selection is 129 predictable, an application can synthesize traffic that will all 130 hash the same, making it possible to launch a denial-of-service 131 attack against the load sharing algorithm, and overload a 132 particular router. This can even be done by a remote application 133 that can cause a host to respond to a given destination address. 134 A special case of this is when the same (single) next-hop is 135 always selected, such as in the algorithm allowed by [ND]. 136 Introducing hashing can make such an attack more difficult; the 137 more unpredictable the hash is, the harder it becomes to conduct a 138 denial-of-service attack against any single router. 140 However, a malicious local application can bypass the algorithm 141 for its own traffic by using mechanisms such as raw sockets, and 142 remote attackers can still overload the routers directly. Hence, 143 the mechanisms discussed herein have no significant incremental 144 impact on Internet infrastructure security. 146 4. IANA Considerations 148 This document has no actions for IANA. 150 5. Acknowledgments 152 The authors of this document would like to thank Erik Nordmark, 153 Brian Haberman, Steve Deering, Aron Silverton, Christian Huitema, 154 and Pekka Savola. 156 6. Normative References 158 [ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 159 for IP Version 6 (IPv6)", RFC 2461, December 1998. 161 [RFC2119] 162 Bradner, S., "Key words for use in RFCs to Indicate 163 Requirement Levels", RFC 2119, BCP0014, March 1997. 165 [ADDRSEL] 166 Draves, R., "Default Address Selection for Internet Protocol 167 version 6 (IPv6)", RFC 3484, February 2003. 169 Draft IPv6 Host to Router Load Sharing June 2005 171 [ROUTERSEL] 172 Draves, R. and D. Thaler, "Default Router Preferences and 173 More-Specific Routes", Work in progress, draft-ietf- 174 ipv6-router-selection-07.txt, January 2005. 176 7. Informative References 178 [MULTIPATH] 179 Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 180 Multicast Next-Hop Selection", RFC 2991, November 2000. 182 8. Authors' Addresses 184 Robert Hinden 185 Nokia 186 313 Fairchild Drive 187 Mountain View, CA 94043 188 Phone: +1 650 625-2004 189 Email: bob.hinden@nokia.com 191 Dave Thaler 192 Microsoft Corporation 193 One Microsoft Way 194 Redmond, WA 98052 195 Phone: +1 425 703 8835 196 EMail: dthaler@microsoft.com 198 9. Full Copyright Statement 200 Copyright (C) The Internet Society (2005). This document is 201 subject to the rights, licenses and restrictions contained in BCP 202 78, and except as set forth therein, the authors retain all their 203 rights. 205 This document and the information contained herein are provided on 206 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 207 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 208 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 209 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 210 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 211 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 212 PARTICULAR PURPOSE. 214 Draft IPv6 Host to Router Load Sharing June 2005 216 10. Intellectual Property 218 The IETF takes no position regarding the validity or scope of any 219 Intellectual Property Rights or other rights that might be claimed 220 to pertain to the implementation or use of the technology 221 described in this document or the extent to which any license 222 under such rights might or might not be available; nor does it 223 represent that it has made any independent effort to identify any 224 such rights. Information on the procedures with respect to rights 225 in RFC documents can be found in BCP 78 and BCP 79. 227 Copies of IPR disclosures made to the IETF Secretariat and any 228 assurances of licenses to be made available, or the result of an 229 attempt made to obtain a general license or permission for the use 230 of such proprietary rights by implementers or users of this 231 specification can be obtained from the IETF on-line IPR repository 232 at http://www.ietf.org/ipr. 234 The IETF invites any interested party to bring to its attention 235 any copyrights, patents or patent applications, or other 236 proprietary rights that may cover technology that may be required 237 to implement this standard. Please address the information to the 238 IETF at ietf-ipr@ietf.org.