idnits 2.17.1 draft-huitema-multi6-experiment-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack an Authors' Addresses Section. ** There are 33 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2640,RFC2641,, RFC, [Bradner], [RFC2460], [RFC2461], [Black], [Bradner,1996], 2462]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) -- Missing reference section? 'Black' on line 362 looks like a reference -- Missing reference section? 'Bradner' on line 365 looks like a reference -- Missing reference section? '1996' on line 319 looks like a reference -- Missing reference section? 'RFC2460' on line 356 looks like a reference -- Missing reference section? 'RFC2461' on line 359 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT C. Huitema 2 Microsoft 3 June 20, 2003 D. Kessens 4 Expires December 20, 2003 Nokia 6 Simple Dual Homing Experiment 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet- Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 The current Internet routing architecture does not provide for a 32 scalable multi-homing solution. Scalability of the interdomain 33 routing architecture is already a problem and is expected to become 34 an even larger problem if millions of home users and small 35 businesses will start to use multi-homing technology in order to 36 achieve redundancy and reliability that traditionally can only be 37 provided by BGP multi-homing. 39 Authors believe that it is possible to solve the problems of end- 40 users and small businesses with a multi-addressing mechanism and 41 source address selection mechanism instead of using the routing 42 system. 44 This draft proposes a setup that will allow us to try a multi- 45 addressing solution. Instead of trying to solve the problems for 46 more complex network setups, it was decided to go for a solution 47 that covers most simple setups but that cover the majority of home 48 and small business networks. Authors believe that we can more easily 49 reach progress by starting with a simple solution that can later be 50 extended to solve the issues of a larger class of users. 52 1. Simple dual homing problem statement 54 In order to make progress towards an IPv6 site multi-homing 55 solution, we propose to start with a simple problem: how to multi- 56 home the simplest site, i.e. a site composed of a single link, e.g. 57 a switched Ethernet network. 59 We believe that addressing the problem of simple, small networks is 60 both urgent and useful. Providing a simple solution for the most 61 numerous networks drastically reduces the danger that generalized 62 multi-homing poses to the Internet. A small network solution may or 63 may not be easily extensible to larger networks, but we know that 64 there are order of magnitude less large networks than small. If we 65 have a solution for the small networks, the scope of the remaining 66 problem will "only" be the hundreds of thousands of larger networks, 67 rather than the hundreds of millions of home networks. 69 Many small business networks use a simple pattern of multi-homing 70 today: the very small business network is composed of a switched 71 Ethernet, combining fixed line and wireless links; it connects to 72 the Internet through two independent connections, such as two DSL 73 lines. There is no coordination between the two providers. In a 74 typical IPv4 set-up, each Internet connection terminates in a 75 different NAT/Firewall; one connection is used as back-up, and is 76 turned on if the other connection fails. 78 Other examples of this simple multi-homing pattern include home 79 networks connected to a broadband service but also maintaining a 80 dial-up connection for back-up; and home networks connected to two 81 broadband connections such as DSL and cable, or perhaps wireless 82 services. 84 2. Define a simple set of requirements 86 For the small networks, the basic motivation for multi-homing is 87 redundancy and reliability. Reliability is defined, as a minimum, as 88 the possibility to maintain operation in cases of failure of one the 89 Internet provider connections [Black]. 91 We will expect the site to contain both "simple" and "smart" hosts. 92 Simple hosts have an implementation of IPv6 conformant to RFC 2641; 93 smart hosts are supposed to be upgraded to become "site multi-homing 94 aware". The reliability expectation is slightly different for the 95 two kinds of hosts. In case of failure of a provider connection, the 96 simple hosts may suffer from a temporary loss of connectivity; the 97 expectation is that operation will shortly resume over the remaining 98 connection; this matches the expectation of current IPv4 "back-up" 99 services. On the contrary, the smart hosts are expected to obtain 100 better services: established TCP-IP connections should survive the 101 loss of one of the provider connections; if connections cannot be 102 maintained, operation should at least resume immediately; it should 103 be possible to perform some amount of load balancing between the two 104 connections. 106 We assume that it is entirely acceptable that the two Internet 107 providers each allocate a "provider aggregated" prefix to the small 108 site. Simple hosts are expected to auto-configure addresses using at 109 least one of these prefixes; smart hosts are expected to auto- 110 configure addresses using both. It is reasonable to expect that 111 hosts have to be renumbered after a connectivity event, although we 112 also expect that addresses configured with one prefix will remain 113 valid as long as this prefix is valid. 115 The following section details specific problems that must be solved 116 by the simple multi-homing solution. 118 3. Multi-homing issues 120 The five multi-homing issues that we want to solve are ingress 121 filtering, avoidance of a "dead connection" for outbound 122 connections, avoidance of a dead address for inbound connections, 123 connection maintenance and exit selection. We believe that the 124 solution to these problems is in the realm of engineering, not 125 research. For each problem, we give hint of one or several possible 126 solutions. We also believe that relatively simple solutions are 127 possible, and should be preferred to "innovative" constructs. 129 3.1. Ingress filtering 131 We assume that each of the ISP may perform ingress filtering, and 132 will reject packets whose source address does not belong to the 133 prefix allocated to the network by that ISP. This leads to a 134 possible failure scenario: 136 * Host choose source address A 137 * Default route leads to router B 138 * Router B forwards the packet to ISP B 139 * Packet is dropped by ingress filtering. 141 The multi-homing proposal must present a solution to this problem. 142 We believe that this solution can be engineered by simple 143 improvements in the small site exit routers, such as checking the 144 source address of the Internet bound packets and redirecting these 145 packets to the "right" exit router in case of problem. This solution 146 should not depend on any particular host behavior, beyond what is 147 mandated by the existing IPv6 specification, notably Neighbor 148 Discovery and Stateless Address Autoconfiguration [RFC2640, RFC2641, 149 RFC 2462]. However, smart hosts may improve on the basic solution, 150 e.g. by selecting a next hop exit router as a function of the source 151 address. 153 3.2. Avoid using dead router for outbound connections 155 The purpose of multi-homing is to provide redundancy, and to avoid 156 the following failure scenario: 158 * Router A is dead, or link to ISP A is dead 159 * Host continue sending using source address A 161 Because of ingress filtering, router B cannot forward the packets 162 The multi-homing proposal must present a solution to this problem, 163 and the solution must work for both simple hosts and smart hosts. We 164 believe that a solution can be engineered by an appropriate use of 165 "router announce" messages, such as stopping advertisement of a 166 provider prefix if the provider connection is unavailable, or 167 possibly advertising this prefix as "deprecated." Smart host may 168 improve on that solution by detecting the loss of connectivity 169 independently of the router advertisements, and automatically 170 preferring the other address for new connections. 172 3.3. Avoid using dead address for outbound connections 174 A variation of the previous failure scenario occurs when a service 175 is hosted on the small network: 177 * Service advertises both address A and address B in the DNS 178 * Router A is dead, or link to ISP A is dead 179 * A remote client selects address A to reach the service 180 * The connection fails 182 The multi-homing proposal must present a solution to this problem, 183 and the solution must work for both simple hosts and smart hosts. A 184 possible solution is to expect remote hosts to retry the connection 185 attempt using the second address; another solution is to somehow 186 update the DNS. 188 3.4. Maintaining connections 190 Solving the ingress filtering and dead router problem provides small 191 site with a functional multi-homing solution, but does not resolve 192 the following failure scenario: 194 * Host has connection with peer P using address A 195 * Router A or ISP A fails 196 * Existing connections break 198 Obviously, the desired outcome is that connections should not break. 199 However, in a similar IPv4 set-up today, e.g. main connection backed 200 up by a DSL line, turning on backup actually breaks connections. 201 Thus, we accept the loss of connections in the case of the simple 202 hosts; the simple hosts will simply have to reestablish their 203 connections. 205 However, the multi-homing proposal should provide smart hosts with a 206 solution to this problem. We believe that it is possible to engineer 207 this solution by using a variation of Mobile IPv6. 209 3.5. Use the right exit/entrance 210 Even if we are able to provide redundancy and reliability, the dual 211 homed networks are still exposed to the following failure mode: 213 * Peer picks address A rather than address B 214 * Resulting traffic is routed on a slower path or on a congested 215 connection 216 * Performance looks terrible 218 The multi-homing proposal should try to provide a solution to this 219 problem, and this solution should be available at least to smart 220 hosts. This is however not as strong a requirement as the other 221 four, as this problem is not solved today in any technology short of 222 full blown traffic engineering. In any case, the goal is not to 223 obtain an absolute optimization of network usage, but rather to 224 avoid the most obnoxious results of load imbalance. 226 We believe that it is possible to engineer a solution using either a 227 smart naming service (a.k.a. DNS load balancing), a routing level 228 optimization such as a randomized choice of exit routers, or 229 possibly a variation of Mobile IPv6 to move existing connections 230 towards a less loaded path. 232 4. Further study 234 The goal of the simple dual homing exercise is to provide a simple 235 solution to the simple sites. We expect further revisions of this 236 draft to report on the results of actual experiments, to detail how 237 proposed solutions fared during these experiments, and to recommend 238 those solutions that were found to work well. 240 Once this goal is achieved, we believe that the solution can be 241 extended in two directions: extend the solution to medium size 242 sites; and extend the solution to accommodate a form of provider 243 independent addressing. 245 The extension to medium size sites can be thought as a progress on a 246 scale of complexity: first, extend the solution to multilink 247 subnets, where all exit routers are on the same link; second, extend 248 the solution to routed network, where all exit routers are on the 249 same link; and third, extend the solution to routed network, where 250 exit routers are present at different locations. 252 Provider independent addressing is often used today by large IPv4 253 sites, which simply obtain a prefix form a registry, use this prefix 254 for internal addresses, and insure that the prefix is distributed in 255 the global routing tables. We believe that similar solutions will be 256 available for large IPv6 sites, but we are also very aware that they 257 cannot be extended to the majority of smaller IPv6 sites. Yet, the 258 small IPv6 sites may benefit from some form of provider independent 259 addresses, e.g. in order to advertise addresses that don't depend on 260 a particular provider configuration. It may be possible for these 261 sites to use a "virtual IP" solution, in which connectivity through 262 a PI address is overlaid on top of the regular provider based 263 addressing. This can be thought of as an extension of the simple 264 solution. 266 5. Security Considerations 268 The proposed solution doesn't change anything to the way Internet 269 routing works. IP packets with a source address out of a prefix from 270 ISP A will leave the exit router on the link that connects to ISP so 271 packet spoofing will not be an issue (or at least, this solution 272 will not make it worse). 274 Smart hosts will not use any mechanisms that will make them more 275 vulnerable for attack than simple hosts. Both smart and simple hosts 276 are vulnerable to the same security risks that are associated with 277 connecting hosts to the Internet and can be addressed with standard 278 security technology. 280 6. IANA Considerations 282 This document does not request any IANA action. 284 7. Copyright 286 The following copyright notice is copied from RFC 2026 [Bradner, 287 1996], Section 10.4, and describes the applicable copyright for this 288 document. 290 Copyright (C) The Internet Society March 21, 2001. All Rights 291 Reserved. 293 This document and translations of it may be copied and furnished to 294 others, and derivative works that comment on or otherwise explain it 295 or assist in its implementation may be prepared, copied, published 296 and distributed, in whole or in part, without restriction of any 297 kind, provided that the above copyright notice and this paragraph 298 are included on all such copies and derivative works. However, this 299 document itself may not be modified in any way, such as by removing 300 the copyright notice or references to the Internet Society or other 301 Internet organizations, except as needed for the purpose of 302 developing Internet standards in which case the procedures for 303 copyrights defined in the Internet Standards process must be 304 followed, or as required to translate it into languages other than 305 English. 307 The limited permissions granted above are perpetual and will not be 308 revoked by the Internet Society or its successors or assignees. 310 This document and the information contained herein is provided on an 311 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 312 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 313 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 314 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 315 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 317 8. Intellectual Property 319 The following notice is copied from RFC 2026 [Bradner, 1996], 320 Section 10.4, and describes the position of the IETF concerning 321 intellectual property claims made against this document. 323 The IETF takes no position regarding the validity or scope of any 324 intellectual property or other rights that might be claimed to 325 pertain to the implementation or use other technology described in 326 this document or the extent to which any license under such rights 327 might or might not be available; neither does it represent that it 328 has made any effort to identify any such rights. Information on the 329 IETF's procedures with respect to rights in standards-track and 330 standards-related documentation can be found in BCP-11. Copies of 331 claims of rights made available for publication and any assurances 332 of licenses to be made available, or the result of an attempt made 333 to obtain a general license or permission for the use of such 334 proprietary rights by implementers or users of this specification 335 can be obtained from the IETF Secretariat. 337 The IETF invites any interested party to bring to its attention any 338 copyrights, patents or patent applications, or other proprietary 339 rights which may cover technology that may be required to practice 340 this standard. Please address the information to the IETF Executive 341 Director. 343 9. Acknowledgements 345 The multi-addressing idea has been debated multiple times by members 346 of the multi6 working group. This draft benefited from detailed 347 comments provided by Tony Li and Lode Coene. 349 10. References 351 Normative references 353 [RFC2460] Deering, S., and R. Hinden, "Internet Protocol, Version 6 354 (IPv6) Specification", RFC 2460, December 1998. 356 [RFC2460] Deering, S., and R. Hinden, "Internet Protocol, Version 6 357 (IPv6) Specification", RFC 2460, December 1998. 359 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 360 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. 362 [Black] Benjamin Black, Vijay Gill, Joe Abley, "Goals for IPv6 Site- 363 Multihoming Architectures", IETF work in progress, May 2003. 365 [Bradner] Bradner, S. [ed], "The Internet Standards Process -- 366 Revision 3", RFC 2026, October 1996 368 Informative references 370 11. Authors' Address 372 Christian Huitema 373 Microsoft Corporation 374 One Microsoft Way 375 Redmond, WA 98052-6399 377 Email: huitema@microsoft.com 379 David Kessens 380 313 Fairchild Drive 381 Mountain View, CA 94041 383 Email: david.kessens@nokia.com 385 Table of Contents: