idnits 2.17.1 draft-ietf-ipv6-host-load-sharing-02.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 3979, Section 5, paragraph 1 on line 224. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 231. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 237. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 187), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 187. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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) == Outdated reference: A later version (-07) exists of draft-ietf-ipv6-router-selection-03 Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 5 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 May 4, 2004 D. Thaler 5 Expires November 2004 Microsoft 7 IPv6 Host to Router Load Sharing 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as "work 24 in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Draft IPv6 Host to Router Load Sharing May 2004 38 Abstract 40 The original IPv6 conceptual sending algorithm does not do load- 41 sharing among equivalent IPv6 routers, and suggests schemes which 42 can be problematic in practice. This document updates the 43 conceptual sending algorithm so that traffic to different 44 destinations can be distributed among routers in an efficient 45 fashion. 47 1. Introduction 49 In the conceptual sending algorithm in [ND] and in the optional 50 extension in [ROUTERSEL], a next hop is chosen when no destination 51 cache entry exists for an off-link destination or when 52 communication through an existing router is failing. Normally a 53 router is selected the first time traffic is sent to a specific 54 destination IP address. Subsequent traffic to the same 55 destination address continues to use the same router unless there 56 is some reason to change to a different router (e.g., a redirect 57 message is received, or the router is found to be unreachable). 59 In both the base algorithm and in the optional extension, 60 sometimes a host has a choice of multiple equivalent routers for a 61 destination. That is, all other factors are equal and a host must 62 break a tie via some implementation-specific means. 64 It is typically desirable when there is more than one equivalent 65 router that hosts distribute their outgoing traffic among these 66 routers. This shares the load among multiple routers and provides 67 better performance for the host's traffic. 69 [ND] does not require any particular behavior in this respect. It 70 specifies that an implementation may always choose the same router 71 (e.g., the first in the list) or may cycle through the routers in 72 a round-robin manner. Both of these suggestions are problematic. 74 Clearly, always choosing the same router does not provide load 75 sharing. Some problems with load sharing using naive tie-breaking 76 techniques such as round-robin and random are discussed in 77 [MULTIPATH]. While the destination cache provides some stability 78 since the determination is not per-packet, cache evictions or 79 timeouts can still result in unstable or unpredictable paths over 80 time, lowering the performance and making it harder to diagnose 81 problems. Round-robin selection may also result in 82 Draft IPv6 Host to Router Load Sharing May 2004 84 synchronization issues among hosts, where in the worst case the 85 load is concentrated on one router at a time. 87 In the remainder of this document, the key words "MUST", "MUST 88 NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 89 "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 90 described in [RFC2119]. 92 2. Load Sharing 94 When a host chooses from multiple equivalent routers, it SHOULD 95 support choosing using some method which distributes load for 96 different destinations among the equivalent routers rather than 97 always choosing the same router (e.g., the first in the list). 98 Furthermore, a host that does attempt to distribute load among 99 routers SHOULD use a hash-based scheme, such as those described in 100 [MULTIPATH], which takes the destination IP address into account. 102 Note that traffic for a given destination address will use the 103 same router as long as the Destination Cache Entry for the 104 destination address is not deleted. With a hash-based scheme, 105 traffic for a given destination address will use the same router 106 over time even if the Destination Cache Entry is deleted, as long 107 as the list of equivalent routers remains the same. 109 3. Acknowledgments 111 The authors of this document would like to thank Erik Nordmark, 112 Brian Haberman, Steve Deering, Aron Silverton, and Christian 113 Huitema. 115 4. Security Considerations 117 As mentioned in [MULTIPATH], when next-hop selection is 118 predictable, an application can synthesize traffic that will all 119 hash the same, making it possible to launch a denial-of-service 120 attack against the load sharing algorithm, and overload a 121 particular router. This can even be done by a remote application 122 that can cause a host to respond to a given destination address. 123 A special case of this is when the same (single) next-hop is 124 always selected, such as in the algorithm allowed by [ND]. 125 Introducing hashing can make such an attack more difficult; the 126 Draft IPv6 Host to Router Load Sharing May 2004 128 more unpredictable the hash is, the harder it becomes to conduct a 129 denial-of-service attack against any single router. 131 5. Normative References 133 [ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 134 for IP Version 6 (IPv6)", RFC 2461, December 1998. 136 [RFC2119] 137 Bradner, S., "Key words for use in RFCs to Indicate 138 Requirement Levels", RFC 2119, BCP0014, March 1997. 140 6. Informative References 142 [MULTIPATH] 143 Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 144 Multicast Next-Hop Selection", RFC 2991, November 2000. 146 [ROUTERSEL] 147 Draves, R. and D. Thaler, "Default Router Preferences and 148 More-Specific Routes", Work in progress, draft-ietf- 149 ipv6-router-selection-03.txt, December 2003. 151 7. Authors' Addresses 153 Robert Hinden 154 Nokia 155 313 Fairchild Drive 156 Mountain View, CA 94043 157 Phone: +1 650 625-2004 158 Email: bob.hinden@nokia.com 160 Dave Thaler 161 Microsoft Corporation 162 One Microsoft Way 163 Redmond, WA 98052 164 Phone: +1 425 703 8835 165 EMail: dthaler@microsoft.com 167 Draft IPv6 Host to Router Load Sharing May 2004 169 8. Revision History 171 (This section to be removed before publication as an RFC) 173 Changes from draft-ietf-ipv6-load-sharing-01.txt: 175 o Changed load sharing from a MUST to a SHOULD. 177 o Added standard IETF intellectual property notice. 179 Changes from draft-ietf-ipv6-router-selection-02.txt: 181 o Split load sharing back into its own document. 183 o Made hash-based, rather than random, the rule. 185 9. Full Copyright Statement 187 Copyright (C) The Internet Society (2004). All Rights Reserved. 189 This document and translations of it may be copied and furnished 190 to others, and derivative works that comment on or otherwise 191 explain it or assist in its implmentation may be prepared, copied, 192 published and distributed, in whole or in part, without 193 restriction of any kind, provided that the above copyright notice 194 and this paragraph are included on all such copies and derivative 195 works. However, this document itself may not be modified in any 196 way, such as by removing the copyright notice or references to the 197 Internet Society or other Internet organizations, except as needed 198 for the purpose of developing Internet standards in which case the 199 procedures for copyrights defined in the Internet Standards 200 process must be followed, or as required to translate it into 201 languages other than English. 203 The limited permissions granted above are perpetual and will not 204 be revoked by the Internet Society or its successors or assigns. 206 This document and the information contained herein is provided on 207 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 208 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 209 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 210 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 211 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 213 Draft IPv6 Host to Router Load Sharing May 2004 215 10. Intellectual Property 217 The IETF takes no position regarding the validity or scope of any 218 Intellectual Property Rights or other rights that might be claimed 219 to pertain to the implementation or use of the technology 220 described in this document or the extent to which any license 221 under such rights might or might not be available; nor does it 222 represent that it has made any independent effort to identify any 223 such rights. Information on the procedures with respect to rights 224 in RFC documents can be found in BCP 78 and BCP 79. 226 Copies of IPR disclosures made to the IETF Secretariat and any 227 assurances of licenses to be made available, or the result of an 228 attempt made to obtain a general license or permission for the use 229 of such proprietary rights by implementers or users of this 230 specification can be obtained from the IETF on-line IPR repository 231 at http://www.ietf.org/ipr. 233 The IETF invites any interested party to bring to its attention 234 any copyrights, patents or patent applications, or other 235 proprietary rights that may cover technology that may be required 236 to implement this standard. Please address the information to the 237 IETF at ietf-ipr@ietf.org.