idnits 2.17.1 draft-ietf-ipv6-host-load-sharing-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 4) being 72 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages 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: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 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 January 26, 2004 D. Thaler 5 Expires July 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 January 2004 38 Abstract 40 The original IPv6 conceptual sending algorithm does not require 41 load-sharing among equivalent IPv6 routers, and suggests schemes 42 which can be problematic in practice. This document updates the 43 conceptual sending algorithm so that traffic to different 44 destinations is distributed among routers in an efficient fashion. 46 1. Introduction 48 In the conceptual sending algorithm in [ND] and in the optional 49 extension in [ROUTERSEL], a next hop is chosen when no destination 50 cache entry exists for an off-link destination or when 51 communication through an existing router is failing. Normally a 52 router is selected the first time traffic is sent to a specific 53 destination IP address. Subsequent traffic to the same 54 destination address continues to use the same router unless there 55 is some reason to change to a different router (e.g., a redirect 56 message is received, or a router is found to be unreachable). 58 In both the base algorithm and in the optional extension, 59 sometimes a host has a choice of multiple equivalent routers for a 60 destination. That is, all other factors are equal and a host must 61 break a tie via some implementation-specific means. 63 It is desirable when there is more than one equivalent router that 64 hosts distribute their outgoing traffic among these routers. This 65 shares the load among multiple routers and provides better 66 performance for the host's traffic. 68 [ND] does not require any particular behavior in this respect. It 69 specifies that an implementation may always choose the same router 70 (e.g., the first in the list) or may cycle through the routers in 71 a round-robin manner. Both of these suggestions are problematic. 73 Clearly, always choosing the same router does not provide load 74 sharing. Some problems with naive tie-breaking techniques such as 75 round-robin and random are discussed in [MULTIPATH]. While the 76 destination cache provides some stability since the determination 77 is not per-packet, cache evictions or timeouts can still result in 78 unstable or unpredictable paths over time, lowering the 79 performance and making it harder to diagnose problems. Round- 80 robin selection may also result in synchronization issues among 81 hosts, where in the worst case the load is concentrated on one 83 Draft IPv6 Host to Router Load Sharing January 2004 85 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 MUST 95 choose using some method which distributes load for different 96 destinations among the equivalent routers. That is, a host MUST 97 NOT always choose the same router (e.g., the first in the list). 98 A host SHOULD use a hash-based scheme, such as those described in 99 [MULTIPATH], which takes the destination IP address into account. 101 Note that traffic for a given destination address will use the 102 same router as long as the Destination Cache Entry for the 103 destination address is not deleted. With a hash-based scheme, 104 traffic for a given destination address will use the same router 105 over time even if the Destination Cache Entry is deleted, as long 106 as the list of equivalent routers remains the same. 108 3. Acknowledgments 110 The authors of this document would like to thank Erik Nordmark, 111 Brian Haberman, Steve Deering, Aron Silverton, and Christian 112 Huitema for their helpful suggestions. 114 4. Security Considerations 116 As mentioned in [MULTIPATH], when next-hop selection is 117 predictable, an application can synthesize traffic that will all 118 hash the same, making it possible to launch a denial-of-service 119 attack against the load sharing algorithm, and overload a 120 particular router. A special case of this is when the same 121 (single) next-hop is always selected, such as in the algorithm 122 allowed by [ND]. Introducing hashing can make such an attack more 123 difficult; the more unpredictable the hash is, the harder it 124 becomes to conduct a denial-of-service attack against any single 125 router. 127 Draft IPv6 Host to Router Load Sharing January 2004 129 5. Normative References 131 [ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 132 for IP Version 6 (IPv6)", RFC 2461, December 1998. 134 [RFC2119] 135 Bradner, S., "Key words for use in RFCs to Indicate 136 Requirement Levels", RFC 2119, BCP0014, March 1997. 138 6. Informative References 140 [MULTIPATH] 141 Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 142 Multicast Next-Hop Selection", RFC 2991, November 2000. 144 [ROUTERSEL] 145 Draves, R. and D. Thaler, "Default Router Preferences and 146 More-Specific Routes", Work in progress, draft-ietf- 147 ipv6-router-selection-03.txt, December 2003. 149 7. Authors' Addresses 151 Robert Hinden 152 Nokia 153 313 Fairchild Drive 154 Mountain View, CA 94043 155 Phone: +1 650 625-2004 156 Email: bob.hinden@nokia.com 158 Dave Thaler 159 Microsoft Corporation 160 One Microsoft Way 161 Redmond, WA 98052 162 Phone: +1 425 703 8835 163 EMail: dthaler@microsoft.com 165 8. Revision History 167 (This section to be removed before publication as an RFC) 169 Changes from draft-ietf-ipv6-router-selection-02.txt: 171 Draft IPv6 Host to Router Load Sharing January 2004 173 o Split load sharing back into its own document. 175 o Made hash-based, rather than random, the rule. 177 9. Full Copyright Statement 179 Copyright (C) The Internet Society (2004). All Rights Reserved. 181 This document and translations of it may be copied and furnished 182 to others, and derivative works that comment on or otherwise 183 explain it or assist in its implmentation may be prepared, copied, 184 published and distributed, in whole or in part, without 185 restriction of any kind, provided that the above copyright notice 186 and this paragraph are included on all such copies and derivative 187 works. However, this document itself may not be modified in any 188 way, such as by removing the copyright notice or references to the 189 Internet Society or other Internet organizations, except as needed 190 for the purpose of developing Internet standards in which case the 191 procedures for copyrights defined in the Internet Standards 192 process must be followed, or as required to translate it into 193 languages other than English. 195 The limited permissions granted above are perpetual and will not 196 be revoked by the Internet Society or its successors or assigns. 198 This document and the information contained herein is provided on 199 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 200 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 201 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 202 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 203 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.