idnits 2.17.1 draft-huitema-multi6-hosts-03.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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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.) -- The document date (February 10, 2004) is 7380 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'TBD IANA' on line 197 -- Looks like a reference, but probably isn't: 'RFC2526' on line 203 -- Looks like a reference, but probably isn't: 'RFC2894' on line 1445 == Unused Reference: '8' is defined on line 2108, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 2115, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 2118, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. '1') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2460 (ref. '2') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '3') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '4') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2553 (ref. '5') (Obsoleted by RFC 3493) ** Downref: Normative reference to an Informational RFC: RFC 3582 (ref. '7') ** Downref: Normative reference to an Historic RFC: RFC 2874 (ref. '8') ** Obsolete normative reference: RFC 2267 (ref. '9') (Obsoleted by RFC 2827) ** Obsolete normative reference: RFC 1886 (ref. '10') (Obsoleted by RFC 3596) -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Obsolete normative reference: RFC 2463 (ref. '14') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 3484 (ref. '15') (Obsoleted by RFC 6724) -- Possible downref: Normative reference to a draft: ref. '16' == Outdated reference: A later version (-03) exists of draft-lear-multi6-things-to-think-about-01 -- Possible downref: Normative reference to a draft: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Huitema 3 Internet-Draft R. Draves 4 Expires: August 10, 2004 Microsoft 5 M. Bagnulo 6 UC3M 7 February 10, 2004 9 Host-Centric IPv6 Multihoming 10 draft-huitema-multi6-hosts-03 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 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 This Internet-Draft will expire on August 10, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 A way to solve the issue of site multihoming is to have a separate 41 site prefix for each connection of the site, and to derive as many 42 addresses for each hosts. This approach to multi-homing, which we 43 call Host-Centric IPv6 Multihoming, has the advantage of minimal 44 impact on the inter-domain routing fabric, since each site prefix can 45 be aggregated within the larger prefix of a specific provider; 46 however, it opens a number of issues, which we will discuss in this 47 memo, including the problem created by the interaction between 48 ingress filtering and multihoming. We then propose a set of specific 49 solutions that enable host centric multihoming, and we review how 50 these solutions meet the goals of IPv6 site multihoming. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Notations . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.1 Requirements language . . . . . . . . . . . . . . . . . . . 5 57 2.2 Reference topology . . . . . . . . . . . . . . . . . . . . . 5 58 2.3 Site exit router . . . . . . . . . . . . . . . . . . . . . . 5 59 2.4 Ingress filtering . . . . . . . . . . . . . . . . . . . . . 5 60 2.5 Site exit anycast identifier . . . . . . . . . . . . . . . . 6 61 2.6 Site exit anycast address . . . . . . . . . . . . . . . . . 6 62 3. Host-Centric IPv6 Multihoming issues . . . . . . . . . . . . 7 63 3.1 Destination address selection . . . . . . . . . . . . . . . 7 64 3.2 Source address selection . . . . . . . . . . . . . . . . . . 7 65 3.3 The site exit issue . . . . . . . . . . . . . . . . . . . . 8 66 3.4 Rapid reaction to topology changes . . . . . . . . . . . . . 9 67 4. Analysis of solutions to the site exit issue . . . . . . . . 10 68 4.1 Relaxing the source address checks . . . . . . . . . . . . . 10 69 4.2 Source address dependent routing . . . . . . . . . . . . . . 11 70 4.3 Source address selection by the host . . . . . . . . . . . . 13 71 4.4 Packet rewriting at exit router . . . . . . . . . . . . . . 15 72 4.5 Comparison of the site exit solutions . . . . . . . . . . . 16 73 5. Analysis of solutions to provide rapid reaction to 74 topology changes . . . . . . . . . . . . . . . . . . . . . . 18 75 5.1 Path selection when establishing a new communication . . . . 18 76 5.1.1 Externally initiated communications . . . . . . . . . . . . 18 77 5.1.2 Internally initiated communications . . . . . . . . . . . . 18 78 5.2 Preserving established communications . . . . . . . . . . . 23 79 6. Integrating Solutions . . . . . . . . . . . . . . . . . . . 24 80 6.1 Solution 1: Relaxing source address checks + Intra site 81 routing system based exit path selection . . . . . . . . . . 24 82 6.2 Solution 2: Source address Discovery + Intra site 83 routing system based exit path selection . . . . . . . . . . 24 84 6.3 Solution 3: Packet Rewriting at site exit + Intra site 85 routing system based exit path selection . . . . . . . . . . 25 86 6.4 Solution 4: Host based exit path selection + source 87 address based routing . . . . . . . . . . . . . . . . . . . 26 88 6.5 Solution 5: Host based exit path selection + site exit 89 discovery . . . . . . . . . . . . . . . . . . . . . . . . . 26 90 6.6 Solution 6: Hybrid approach + source address dependent 91 routing . . . . . . . . . . . . . . . . . . . . . . . . . . 27 92 6.7 Solution 7: Hybrid approach + source address selection 93 by the host . . . . . . . . . . . . . . . . . . . . . . . . 27 94 6.8 Remaining combinations . . . . . . . . . . . . . . . . . . . 28 95 7. Proposed solution . . . . . . . . . . . . . . . . . . . . . 29 96 7.1 Multihoming solutions for small sites . . . . . . . . . . . 29 97 7.1.1 Step 1: preserving functionality for legacy hosts when 98 becoming multihomed. . . . . . . . . . . . . . . . . . . . . 29 99 7.1.2 Step 2: Optimizations to enhance the multihoming support . . 31 100 7.2 Multihoming solution for medium sites . . . . . . . . . . . 36 101 7.2.1 Reaction to topology changes . . . . . . . . . . . . . . . . 36 102 7.3 Multihoming solution for big sites . . . . . . . . . . . . . 37 103 8. Evaluation of Host centric solution and Multihoming Goals . 39 104 8.1 Capabilities of IPv4 Multihoming . . . . . . . . . . . . . . 39 105 8.1.1 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . 39 106 8.1.2 Load Sharing . . . . . . . . . . . . . . . . . . . . . . . . 40 107 8.1.3 Performance . . . . . . . . . . . . . . . . . . . . . . . . 40 108 8.1.4 Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 109 8.1.5 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . 40 110 8.1.6 Transport-Layer Survivability . . . . . . . . . . . . . . . 40 111 8.2 Additional Goals . . . . . . . . . . . . . . . . . . . . . . 40 112 8.2.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 40 113 8.2.2 Impact on Routers . . . . . . . . . . . . . . . . . . . . . 41 114 8.2.3 Impact on Hosts . . . . . . . . . . . . . . . . . . . . . . 41 115 8.2.4 Interaction between Hosts and the Routing System . . . . . . 41 116 8.2.5 Operations and Management . . . . . . . . . . . . . . . . . 41 117 9. Things MULTI6 Developers should think about . . . . . . . . 42 118 9.1 The Answers . . . . . . . . . . . . . . . . . . . . . . . . 42 119 9.1.1 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 42 120 9.1.2 Identifiers and locators . . . . . . . . . . . . . . . . . . 42 121 9.1.3 On The Wire . . . . . . . . . . . . . . . . . . . . . . . . 42 122 9.1.4 Names, Hosts, Endpoints, or none of the above? . . . . . . . 44 123 10. Security Considerations . . . . . . . . . . . . . . . . . . 49 124 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 50 125 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 126 References . . . . . . . . . . . . . . . . . . . . . . . . . 52 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53 128 Intellectual Property and Copyright Statements . . . . . . . 54 130 1. Introduction 132 There are two basic forms of multihoming, multiple interfaces per 133 host and multiple site connections shared by many hosts. This working 134 group is specifically concerned with site multi-homing. A way to 135 solve the issue of site multihoming is to have a separate site prefix 136 for each connection of the site, and to derive as many addresses for 137 each hosts; this can in fact be supported by a combination of router 138 renumbering (RFC2894) and Stateless Address Autoconfiguration 139 (RFC2462). This approach to multi-homing, which we call Host-Centric 140 IPv6 Multihoming, has the advantage of minimal impact on the inter- 141 domain routing fabric, since each site prefix can be aggregated 142 within the larger prefix of a specific provider; however, it opens a 143 number of issues, which we will discuss in this memo, including the 144 problem created by the interaction between ingress filtering and 145 multihoming. We then propose a set of specific solutions that enable 146 host centric multihoming, and we review how these solutions meet the 147 goals of IPv6 site multihoming. 149 2. Notations 151 2.1 Requirements language 153 In this document, the key words "MAY", "MUST", "MUST NOT", 154 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 155 interpreted as described in [13]. 157 2.2 Reference topology 159 In the following discussion, we will use this reference topology: 161 /-- ( A ) ---( ) --- ( C ) --\ 162 X (site X) ( IPv6 ) (Site Y) Y 163 \-- ( B ) ---( ) --- ( D ) --/ 165 The topology features two hosts, X and Y, whose respective sites are 166 both multi-homed. Host X has to global IPv6 addresses, which we will 167 note "A:X" and "B:X", formed by combined the prefixes allocated by 168 ISP A and B to "site X" with the host identifier of X. Similarly, Y 169 has two addresses "C:Y" and "D:Y". 171 We assume that X, when it starts engaging communication with Y, has 172 learned the addresses C:Y and D:Y, for example because they were 173 published in the DNS. We do not assume that the DNS is dynamic: there 174 will be situations in which both C:Y and D:Y are published, while in 175 fact only one is reachable. We assume that Y, when it receives 176 packets from X, has only access to information contained in the 177 packet coming from X, e.g. the source address; we do not assume that 178 Y can retrieve by external means the set of addresses associated to 179 X. 181 2.3 Site exit router 183 A site exit router is an IPv6 router managing at least one of the 184 connections between a site and the Internet. 186 2.4 Ingress filtering 188 Ingress filtering refers to the verification of the source address of 189 the IP packets at the periphery of the Internet, typically at the 190 link between a customer and an ISP. This process, which is described 191 in [9] is intended to thwart a class of denial of service attacks in 192 which attackers hide their identity by using a "spoofed" source 193 address. 195 2.5 Site exit anycast identifier 197 A 7 bit anycast identifier whose value is XX. [TBD IANA] 199 2.6 Site exit anycast address 201 An IPv6 anycast address built by combining an IPv6 address prefix 202 allocated to the site with the site exit anycast identifier, 203 according to the rules specified in [RFC2526]. The proposed used of 204 this anycast address is detailed in section 5. 206 3. Host-Centric IPv6 Multihoming issues 208 Host-Centric IPv6 Multihoming forces hosts to choose the source and 209 the destination address of the IPv6 packets, in a way that makes the 210 best usage, or at least a reasonable usage, of the network resource. 211 Hosts must first select a destination address, and will then perform 212 source address selection. Source address selection must be consistent 213 with ingress filtering, which is sometime implemented at network 214 interfaces: we call this the "site exit" issue. Destination address 215 selection is often based on incomplete or obsolete information, which 216 can be harmful if, for example, hosts fail to notice that one of the 217 site's connections is suddenly made unavailable. In any case, we must 218 also consider "low budget" hosts, and make sure that these hosts can 219 get some benefits from multihoming without enduring too much cost. 221 3.1 Destination address selection 223 It is fairly common for hosts to have to choose between multiple 224 destination addresses for a peer. TCP performs this choice when the 225 connection is instantiated; SCTP may perform similar choices through 226 the life-time of the connection; UDP may perform this choice either 227 for each packet, or at the beginning of an association. We may debate 228 whether hosts have sufficient information to perform a valid choice, 229 and it is a complex debate. Some very simple appliances probably 230 never will have any information; large servers potentially have tons 231 of information available; personal computers are somewhere in 232 between. It is not unrealistic to expect progress in this area, 233 either by communication between the hosts and the routers, by sharing 234 of experience between hosts, or maybe by innovative application 235 design that would for example implement a file transfer by parallel 236 retrieval of fraction of the file from multiple sources. At worst, a 237 host can always try the proposed addresses one by one, and pick the 238 first one that actually works -- not very elegant, but definitely 239 workable. 241 3.2 Source address selection 243 The source address selection in most hosts immediately follows the 244 destination address selection. When a host has multiple interfaces, 245 the normal procedure is to select the destination address, then 246 identify the interface over which packets bound to that address will 247 be routed, and finally select a source address associated to that 248 interface. When the host has multiple addresses attached to an 249 interface, which is the case with host centric IPv6 multihoming, the 250 host could in theory pick any of these addresses, or at least any of 251 those that have an appropriate scope. In our example topology, 252 supposing that X has selected the destination address "C:Y", it can 253 choose as source address either "A:X" or "B:X". 255 Choosing the source address will affect the reverse path of the 256 connection, as the source address of the message will become the 257 destination address of the responses. This may be a serious matter in 258 asymmetric applications like web access, in which the bulk of the 259 data is sent by the server to the client. If the multiple addresses 260 correspond to different ISP, the hosts should normally pick the 261 source address that will provide the best performances. As for 262 destination address selection, we may expect that the host will have 263 some knowledge of the effect of choosing one or the other address, 264 for example by observing that web pages are served faster through one 265 address than through the other. 267 3.3 The site exit issue 269 A special complication appears when the ISPs who serve the multihomed 270 site perform "source address selection." In our generic 271 configuration, we assume that X is served by ISP A and B, and thus 272 can be reached by the addresses A:X and B:X. We also we assume that Y 273 is served by ISP C and D, and thus can be reached by the addresses 274 C:Y and D:Y. To communicate with Y, X will choose the destination 275 address that appears to be easier to reach, for example D:Y; then, it 276 will choose the source address that provides the most efficient 277 reverse path, say A:X. 279 Suppose now that the ISP connections at Site X are managed by two 280 different site exit routers, RXA and RXB, and that there is a similar 281 configuration at Site Y, with routers RYC and RYD. 283 /-- ( A ) ---( ) --- ( C ) --\ 284 (RXA) ( ) (RYC) 285 X (site X) ( IPv6 ) (Site Y) Y 286 (RXB) ( ) (RYD) 287 \-- ( B ) ---( ) --- ( D ) --/ 289 Within Site X, the interior routing will decide which of RXA or RXB 290 is the preferred exit router for the destination "D:Y"; similarly, 291 within Site Y, the interior routing will decide which of RYC or RYD 292 is the preferred exit for destination A:X. If the chosen exit router 293 at Site X is RXA, the packet will flow freely to RYD; If the chosen 294 exit router at Site Y is RYD, the response will also flow freely. 295 However, if the exit routers are RXB or RYC, and if the ISPs perform 296 ingress filtering, we have a problem: ISP B sees a packet coming from 297 RXB, whose source address does not match the prefix assigned by B to 298 X; ISP C, similarly, sees a packet whose source address does not 299 match the prefix assigned by that ISP to Y. If either of these ISPs 300 decides to drop the packet, the communication will be broken. 302 3.4 Rapid reaction to topology changes 304 Network conditions change over time. In order to meet the performance 305 requirement, we must allow the use of the best path at any time; In 306 order to meet the "redundancy" requirement, we have to make sure that 307 if a network connection breaks, the corresponding prefix is not used 308 as either a source or a destination address. 310 We may assume that the destination address selection algorithm 311 mentioned in 3.1 will naturally result in the selection by X of an 312 appropriate address for Y; X may for example try in turn the 313 addresses C:Y and D:Y, and retain the address for which a response 314 comes back. However, we must make sure that X selects a source 315 address that will be reachable: for example, if the link to ISP A 316 fails, X must make sure that it uses as source address B:X, not A:X. 318 4. Analysis of solutions to the site exit issue 320 The site exit issue is caused by ingress filtering at the site 321 egress. In this section, we will analyse four ways to solve the 322 issue: somehow relax the source address check, implement source 323 address dependent routing, ask hosts to pick "the right" source 324 address, or ask routers to somehow rewrite the packets so that it can 325 pass the source address checks. We will then compare the proposed 326 solutions, in order to prepare a recommendation. 328 4.1 Relaxing the source address checks 330 An obvious way to avoid failures due to ingress filtering is to 331 simply make sure that all the addresses used by the hosts of a given 332 site will be considered acceptable by each of the site's providers. 333 In our site X example, that would mean that provider A would accept 334 addresses of the form "B:X" as valid, and that provider B will in 335 turn accept addresses of the form "A:X" as valid. 337 One way to achieve this is simply to ask the service provider to turn 338 off source address checks on the site connection. This requires a 339 substantial amount of trust between the provider and the site, as 340 source address checks are in effect delegated to the site routers. 341 One possible way to achieve this trust is to make sure that the site 342 routers, or possibly the site firewalls, meet a quality level 343 specified by the provider. 345 Another way to achieve this relaxed level of checking is to check 346 source addresses against a list of "authorized prefixes" for the site 347 connection, rather than simply the single prefix delegated by the 348 provider. This solution requires that the site communicates the 349 authorized prefixes to the provider, either through a management 350 interface or through a routing protocol. This is obviously more 351 complex than simply lifting the controls, and in fact ends up with a 352 very similar requirement of trust: the provider has to believe that 353 the site will transmit the right prefixes. 355 A special case occurs when the site exit is an "automatic tunnel" 356 interface, such as 6to4 or Teredo. Source address control for 357 automatic tunnels is delegated to the "other side" of the tunnel, in 358 practice to a very large number of relay routers located across the 359 Internet. Checks are based on the correlation between the IPv6 source 360 address and the IPv4 source address used in the tunneling protocol. 361 Asking each potential end of the tunnel to relax its checks is not 362 realistic; in practice, this means that the exit routers will have to 363 obtain the right to use as source address a privileged IPv4 address, 364 such as the 6to4 anycast address; this will imply a negotiation with 365 the provider of the IPv4 service. 367 In conclusion, relaxing the source address checks requires some form 368 of explicit trust between the site and its providers. There is no 369 doubt that this level of trust will exist in many cases; there is 370 also no doubt that there will be many cases in which the provider is 371 unwilling to grant this trust, particularly in the case of small 372 sites, such as for example home networks dual-homes to a DSL provider 373 and a cable network provider. 375 4.2 Source address dependent routing 377 Another solution to the site exit problem is to perform some kind of 378 source routing within the site, so that the site exit is effectively 379 a function of the source address in the packet. Current routers 380 generally do not implement any kind of source address dependent 381 routing; this implies that this solution would have to be "rolled in" 382 progressively in the site, following a generic schema such as: 384 Multiple site exits 385 | | | | 386 -----+-----+-----+-----+----- 387 ( ) 388 ( Source based routing domain ) 389 ( ) 390 ----+----+----+----+----+---- 391 ( ) 392 ( Generic routing domain ) 393 ( ) 394 ----------------------------- 396 In this schema, all site exit routers are connected to a source based 397 routing domain. Packets initiated in the generic routing domain and 398 bound to an "out of site" address are passed to the nearest access 399 point to the source based routing domain, using classic "hot potato" 400 routing. The routers in the source based routing domain maintain as 401 many parallel routing tables as there are valid source prefixes, and 402 would choose a route that is a function of both the source and the 403 destination address; the packets exit the site through the "right" 404 router. There are multiple possible implementations of this general 405 concept. 407 The simplest implementation is to have only one exit router for the 408 site; this exit router chooses the exit link on the basis of the 409 source address in the packet. This simple implementation might be 410 adequate for very small sites, but introduces a single point of 411 failure, and thus fails to meet the "redundancy" requirement of 412 multihoming. 414 In the most complex set up, each router of the site would maintain as 415 many parallel routing tables as there are valid source prefixes, and 416 would choose a route that is a function of both the source and the 417 destination address. This solution enables "shortest path" routing 418 and can provide an arbitrary level of redundancy. However, 419 maintaining parallel routing tables requires a massive re-engineering 420 of routers and routing protocols, and thus would be hard to deploy in 421 the short term. 423 A slightly less complex implementation is to connect all exit routers 424 to the same link, e.g. to what is often referred to as the "DMZ" for 425 the site. This solution requires that all routers connected to the 426 DMZ are upgraded to perform source address based routing. This 427 configuration is less fragile than a single router solution; however, 428 the single link requirement seems to preclude "geographic redundancy" 429 between the site exits. It does requires the re-engineering of some 430 routers, but not necessarily all routers of the site. In practice, it 431 could be a way to "phase in" the most complex setup described in the 432 previous paragraph. 434 A much simpler alternative is to establish a mesh of "tunnels" 435 between the site exit routers. A site exit router that receives a 436 packet bound for an out-of-site address would perform a source 437 address check before forwarding the packet on one of its outgoing 438 interfaces; if the source address check is positive, the packet will 439 effectively be sent on the interface; if it is not, the packet would 440 be "tunneled" to a more adequate router. 442 The main requirement of the tunneling alternative is that site-exit 443 routers be able to perform address checks, and that each site exit 444 router be able to associate to each valid site prefix the address of 445 a corresponding site exit router. An obvious possibility is to 446 configure prefixes and corresponding addresses in each router; it 447 would however be preferable to derive these addresses automatically. 448 A strong assumption of the IPv6 architecture is that all prefixes of 449 a site will have the same length; it is thus possible to derive a 450 prefix from the source address of a "misdirected" packet, by 451 combining this prefix with a conventional suffix. The suffix should 452 be chosen to not collide with the subnet numbers used in the site; a 453 null value will be inadequate, since it could be matched by any 454 router with knowledge of the prefix, not just the site exit router; a 455 value of "all ones" could be adequate. 457 In order to enable tunneling, each router managing a site prefix will 458 then inject a "host route" for its locally managed prefixes in the 459 interior routing protocol. Site exit routers performing automatic 460 tunneling can then use the standard routing procedures to detect 461 whether the anycast address corresponding to the prefix in use is 462 reachable; they can automatically reject, rather than tunnel, packets 463 whose source address does not correspond to a reachable anycast 464 address. 466 An inconvenience of the set-up is that some packet will follow a less 467 than direct path; we will see in the next section how that could be 468 palliated by host based processing. 470 Source based routing allows for a large diversity between the site 471 exits; it also allows for host based policy decision, since a host 472 can influence the routing of a packet by choosing the appropriate 473 source address. There is however one drawback of any source address 474 based scheme, the impossibility to use "asymmetric" path between two 475 sites: 477 ..................................> 478 ./-- ( A ) ---( ) --- ( C ) --\... 479 .....>(RXA) ( ) (RYC)....> 480 X (site X) ( IPv6 ) (Site Y) Y 481 <.....(RXB) ( ) (RYD)<.... 482 . \-- ( B ) ---( ) --- ( D ) --/... 483 <................................... 485 Using source based routing implies that if the host X chooses the 486 source address B:X, then its packets will exit through router RXB, 487 never through RXA. This may provide lesser performances if a link is 488 congested in one direction but not in the other. However, source 489 based routing would allow four paths, A-C, A-D, B-C and B-D, thus 490 providing an adequate redundancy and allowing a great deal of 491 performance optimization. 493 4.3 Source address selection by the host 495 The site exit issue would be mitigated if the hosts chose a source 496 address that would be compatible with the exit point chosen by the 497 routing protocol, or alternatively if the host tunneled the packet 498 directly to an adequate exit router. 500 The first alternative could be called "source address discovery". In 501 many ways, source address discovery is similar to path MTU discovery. 502 The two issues are similar: packets that do not meet some criteria 503 fixed by the network are dropped; the host has to find the cause of 504 the loss, and to take action in order to make sure that these packets 505 will be accepted. In the path MTU case, the action is to use shorter 506 packets; in the ingress filtering case, the action is to present a 507 different source address. 509 To implement source address discovery, the hosts would have to 510 introduce a "preferred source address" parameter in the "destination 511 cache" mentioned in the Neighbor Discovery standard [3]. The primary 512 purpose of the cache is to link a destination address to a next hop 513 neighbor; it is also the repository of per-destination parameters 514 such as the path MTU; it is the natural repository for the new 515 parameter. The source prefix in the destination cache would be used 516 during source address selection, to select an available interface 517 address that matches the prefix. 519 As for path MTU discovery, source address discovery requires that the 520 hosts receive some information from the network. Such information can 521 be conveyed in an ICMP Destination Unreachable error message with 522 code 5 which means source address failed ingress policy [18]. The 523 router is supposed to send such message when the packet is discarded 524 because of ingress filtering issues. The error message contains 525 information about the packet that triggered the error. However, the 526 host will also need information about the source address prefix that 527 should be used to pass the source address check. The proposed format 528 of the error message does not includes such information. However, a 529 proper choice of the source address by the router that generates the 530 message can provide a good substitute. This means that the router 531 that generates the error message will have to include the prefix that 532 complies with the ingress filtering in the source address of the 533 packet that carries the error message. The host will then select the 534 source address to be used for the selected destination by performing 535 a longest prefix match between the source address contained in the 536 error message and the potential source addresses. In the absence of 537 an explicit ICMP message, the hosts would have to rely on a trial an 538 error process, noticing that packets get dropped and trying 539 retransmissions with alternate source addresses; the experience of 540 path MTU discovery shows that such processes are awkward and error 541 prone. 543 An alternative to source address discovery is "exit router 544 discovery", i.e. the discovery by the source of the preferred exit 545 router for a given source address. This requires a slightly different 546 change to the caches used in neighbor discovery, specifically the 547 management of a "source exit cache" that associates a specific source 548 address with an exit router, or maybe the combination of a 549 destination address and a source address with an exit router. As with 550 source address discovery, this would be learned through an ICMP 551 message; this message would not be an error message, but rather a 552 variation of the redirect message. After receiving such messages, the 553 host will tunnel to the specified exit point the packets sent from 554 the source address to the destination; the exit point will 555 decapsulate these packets and send them over the appropriate exit 556 link. 558 The "exit router discovery" procedure appears to be superior to the 559 "source address discovery." Both solutions require approximately the 560 same amount of resource in the host, but the exit router discovery 561 has two advantages: it enables hosts to actually specify the point of 562 exit from the site, thus giving them a greater amount of "policy 563 control". 565 We should note that neither "source address discovery" nor "exit 566 router discovery" are implemented in current hosts. In order to 567 accomplish the goal expressed in [7] that hosts implementing the 568 current version of IPv6 can continue to operate in a multi-homed 569 site, even if they would not take advantage of multihoming; in 570 consequence, these procedures can only be used as an optional 571 optimization. 573 4.4 Packet rewriting at exit router 575 In section 4.2, we explained how a site exit router that discovers 576 that a packet bound out of the site has the "wrong" source address 577 can route the packet to an alternative exit. Another way to pass the 578 source the source address check is to modify the packet, which could 579 in theory be done by replacing the source address or by encapsulating 580 the packet using "IPv6 in IPv6". 582 In fact, replacing the source address is not necessarily a good idea, 583 since this will remove information from the packet; it also requires 584 some level of cooperation between the exit router and the host, if 585 only to understand what alternative source addresses can be used by 586 the host, if any. 588 One could preserve the information by encapsulating the packet in a 589 new IPv6 header, using "IP in IP". The source address of the new 590 header will be the address used by the router on the exit interface, 591 the destination address will be the original destination, and the 592 payload type will be set to "IPv6." After the insertion of the 593 option, the outgoing packet will have the following values: 595 * outer IPv6 header source address: address of the site egress 596 interface, 598 * outer IPv6 header destination address: from initial packet, 600 * outer IPv6 header payload type: "IPv6", 602 * inner IPv6 header source address: source address of initial packet, 604 * inner IPv6 header destination address: from initial packet, 605 * inner IPv6 header payload type: payload type of initial packet, 607 4.5 Comparison of the site exit solutions 609 The four solutions that we have reviewed have different advantages 610 and inconveniences. The may differences are in terms of 611 deployability, generality, redundancy, policy control, and impact on 612 existing hosts, i.e. minimal implementations of IPv6 that would use 613 only one of the available prefix for the site, that would not perform 614 any more sophisticated logic than picking a destination address at 615 random among multiple alternatives, and that would not understand any 616 additional IPv6 option or any additional ICMP message. 618 The relaxation of source address checks detailed in 4.1 is easy to 619 deploy, and would not affect minimal hosts. It is a perfectly 620 reasonable solution for large sites, i.e. the sites that benefit of 621 IPv4 multihoming today: it should not be more complex to convince a 622 provider to relax address checks for a particular customer tomorrow, 623 than to convince today a similar provider to advertise in its routing 624 table the global IPv4 address of the site. If we choose this 625 solution, we should choose its simplest implementation, i.e. one in 626 which the provider completely delegates source address checks to the 627 site's router or firewalls. This is however not a general solution, 628 since we cannot expect all sites to convince every provider to relax 629 their checks. 631 The rewriting at exit routers appears to be an inferior solution. It 632 is not really easier to implement than the "tunneling" variation of 633 source routing at the exit sites: if a router can detect that a 634 source address does not pass the checks for a proposed interface, and 635 if it can encapsulate the packet before forwarding it, then it could 636 just as well tunnel the packet to the "correct" exit router for the 637 site. Tunneling the packet to its final destination actually has a 638 larger impact on the existing hosts than simply tunneling the packet 639 to another router: we have to assume that the destination host is 640 willing to accept tunneled packets, which is not an obvious 641 proposition. Since the packet is tunneled, the destination host has 642 to trust that the source address in the encapsulated packet is 643 genuine; in the absence of an authentication header, this is risky 644 proposition. 646 When the source address checks cannot be relaxed, the best solution 647 is probably to perform some kind of source address based routing to 648 the adequate exit router. In the long term, the IETF may develop 649 internal routing protocols that take into account the source address 650 as part of the "reachability information" for a set of destinations; 651 in the short term, there are no such protocols, and we have to rely 652 on a tunneling mechanism between site exit routers. 654 Exit router discovery is a natural complement of the tunneling 655 mechanism between site exit routers. When an exit router tunnels a 656 misdirected packet towards another exit, it may send an appropriate 657 "exit redirection" ICMP message. If the host is a minimal IPv6 host, 658 the ICMP message will be ignored; further packets will continue using 659 the same slightly sub-optimal path. On the other hand, if the host 660 has been upgraded to take advantage of multi-homing, the packets will 661 be tunneled to the appropriate exit router; they will follow a direct 662 path to this router. 664 5. Analysis of solutions to provide rapid reaction to topology changes 666 In order to fulfill the "redundancy" requirement, a multihoming 667 solution has to provide the means to identify the available exit 668 paths towards a given destination and carry packets through it. In 669 other words, a mechanism to detect unavailable exit paths is 670 required, so that they are not used. We will analyze the different 671 mechanisms to perform the path selection in two situations: path 672 selection when establishing a new communication and path selection 673 during the lifetime of a communication. These two problems are quite 674 different, since the timing requirements are different in the two 675 situations and also requirements imposed in the addresses to be used 676 are different. 678 5.1 Path selection when establishing a new communication 680 5.1.1 Externally initiated communications 682 We will first analyze the mechanism used by hosts outside the 683 multihomed site to select among the paths to the multi-homed site. We 684 have already assumed that the multihomed site will have as many 685 prefixes as ISPs, and that it will assign multiple addresses to every 686 host that will benefit from multihoming. It is also assumed that 687 those addresses will be announced through the DNS. 689 So, when an external host tries to establish a communication, it will 690 first obtain all the host's addresses from the DNS. Then it will try 691 to use one of them and if it succeeds the communication is 692 established; and if not, it will try with the next address. 693 Considering that each address is routed through one and only one 694 provider, the selection of an address implies the selection of a 695 provider, then it implies the selection of a incoming path to the 696 multihomed site. So, for external hosts, incoming path failure 697 detection and incoming path selection is already being performed by 698 the external host itself and the provided capabilities are enough to 699 provide support to the multihomed environments. When the host within 700 the multihomed site replies to the incoming packet, both the 701 destination and the source addresses are already determined, so no 702 selection has to be performed by the host in the multi-homed site. 703 Moreover, since the incoming packet has reached the host within the 704 multihomed site, and assuming that some mechanism to guarantee 705 ingress filtering compatibility mechanism is being used, the exit 706 path will be the same than the ingress path, so it is likely to be 707 working properly. 709 5.1.2 Internally initiated communications 711 We will next analyze the mechanisms required within the multihomed 712 site to select among the multiple path connecting the site to the 713 Internet. When a host within the multihomed site sends a packet to a 714 given external destination address, the exit path through which the 715 packet will be routed has to be selected. In order to select a path 716 two mechanisms are needed: a mechanism to discover the available 717 paths and a mechanism to route the packets through the path 718 identified as available. We have two elements that may perform these 719 tasks: the routing system and the host itself. 721 We will analyze the following possibilities: 723 The first possibility is to let the intra-site routing system perform 724 both tasks. 726 The second possibility presented is to let the host do both tasks. 728 The third possibility is to use the routing system to identify the 729 available paths and to use a mechanism in the host to force the 730 routing of packets through the identified path. 732 The fourth possibility where the host identifies the available path 733 and the routing system routes the packet through the path identified 734 by the host doesn't seems a reasonable approach to us, so it will not 735 be included in our analysis. 737 5.1.2.1 Exit path selection by the intra-site routing system 739 One possibility is to let the intra-site routing system perform the 740 complete exit path selection mechanism. In order to do that, 741 intra-site routing system requires information about which 742 destinations are reachable through each one of the exit paths. This 743 means that each one of the providers has to inform the multi-homed 744 site which destinations are reachable through him. Normally, the BGP 745 protocol is used for this task. From the multihomed site perspective, 746 there are two difficulties with this approach: first, the amount of 747 information that is to be injected in the intra-site routing system 748 is important and second, running the BGP protocol is more than a 749 trivial task. While there are some medium-big multihomed sites that 750 certainly can deal easily with these two issues, other smaller 751 multi-homed sites may not deal with them so easily (imagine for 752 instance a site consisting a few PCs on a single Ethernet and a 753 single router connected to the Internet through a DSL access and a 754 cable access). 756 We can explore approaches to try to reduce the amount of routing 757 information to be injected to the multi-homed site. The most 758 aggressive approach would be to inject only a default route through 759 each of the ISPs. This case works fine when one of the direct links 760 between the multihomed site and ISP fails, but, if we only want to 761 provide protection for this specific case, RFC 3178 provides a 762 solution that it is simpler overall since it deals with all the 763 problems for this particular case (like ingress filtering, transport 764 survivability, etc). So, since we are looking for a solution that 765 provides better fault tolerance capabilities than RFC 3178, we need 766 more information to be injected to the intra-site routing system. 768 We need then alternatives that allow us to obtain better fault 769 tolerance. A possible approach is to filter the accepted routes based 770 on the AS path length, as proposed in [12]. By this mechanisms, the 771 multihomed site would only accept routes with an AS path attribute 772 whose length is no longer than x ASes. This approach allows reducing 773 the amount of routing information while still achieving a high level 774 of fault tolerance. The value of x is a trade-off between the two of 775 them. As more routing information is injected into the site (higher 776 x), better path selection will be performed and better fault tolerant 777 capabilities will be provided by the solution, but at the same time 778 more resources will be needed within the multihomed site. However, 779 configuring filters raises the difficulty of running BGP, requiring 780 additional BGP expertise in the end-site, making the adoption of this 781 solution harder for small unmanaged sites. 783 5.1.2.2 Host based exit path selection 785 An alternative to intra-site routing system exit path selection is to 786 move exit path selection to the host itself. In order to enable the 787 host to perform the exit path selection, two mechanisms are needed: a 788 mechanism to discover available paths and a mechanism to enable the 789 host to force the routing of packets through the selected exit path, 790 overruling intra-site routing system routing. 792 5.1.2.2.1 Mechanisms to force the routing of packets. 794 A possible mechanism to let the host force the path of the packets is 795 to make a tunnel directly to the exit router. In order to do that, 796 the host must be able to discover the address of the exit router. 797 Using an "Exit Router Discovery" ICMP message as presented in section 798 4.3 would be an option. An alternative to tunnels could be the usage 799 of routing headers. However this is considered an inferior solution 800 since the routing header would be carried all along the path to the 801 final destination even if it were not needed. 803 Another mechanism to enable the host to select the exit path is 804 available when some form of source address dependent routing is used 805 within the multihomed site. As it has been presented in section 4.2, 806 if each exit ISP is associated with one of the available prefixes, 807 and source address dependent routing is used, selecting the prefix to 808 be included in the source address implies the selection of the exit 809 ISP through which the packet will be carried. So, source address 810 dependent routing can be considered as an option to allow the host to 811 select the exit path. 813 5.1.2.2.2 Mechanism to discover available and unavailable paths 815 A mechanism to identify available paths is just to let the host do 816 trial and error procedure. That is, in order to reach a certain 817 destination, the host tries every possible exit path. The procedure 818 can be carried out either sequentially or in parallel, that is, the 819 host can try with every path simultaneously or it can try with one 820 path and if the chosen path fails then it tries with the next one. 821 The benefits and drawbacks of these two approaches are clear: the 822 sequential procedure may take longer to find the available path, but 823 the parallel procedure consumes more resources since multiple packets 824 are sent every time an available path has to be discovered. 826 However, the implementation of a failure detection mechanism based on 827 sending packets may be trickier than what it may seem. A possible 828 approach could be to define a new protocol for detecting available 829 paths that sends probe packets end to end. However, a solution that 830 doesn't impose changes in hosts outside the multihomed site is 831 preferred because it is easier to deploy. So, we have to use already 832 available mechanisms. Among the available choices, we could use ICMP 833 echo packets to detect path availability. The problem here is the 834 wide adoption of ICMP filtering because security issues. 836 The other available option is to use data packets as probes. The main 837 problem here is that not all applications are bi-directional, so 838 there may be cases when no packets will return but the path is 839 available. However, we consider that an important number of 840 applications are bi-directional, so we will explore this possibility 841 (Note that we are not considering the multicast case here, where the 842 unidirectional flows are more common). So, a path failure detection 843 mechanism based on data packets stores the exit path information 844 corresponding to a destination address in a cache, the Exit Path 845 Cache. The information contained in this cache depends on the 846 mechanism that is used to force the routing of the packet by the 847 host. If the tunnel mechanism is used, the address of the exit router 848 and the source address to be included are cached. If source address 849 based routing is used, only the source address to be used is cached. 851 So, when a packet is to be sent to a certain destination address, the 852 Exit Path Cache is searched for an exit path corresponding to the 853 destination address. If no exit path is found in the cache, the host 854 has no knowledge about the available paths, so it has to start the 855 failure detection procedure by sending packets through all the 856 available paths. As we have seen, such procedure can be performed 857 sequentially or in parallel, but in any case packets will be sent 858 through the available paths and the host will wait for replies. When 859 the first reply is received (whether because packets through all 860 available paths have been sent simultaneously or because packets 861 through different exit paths have been sent and a timeout has 862 occurred, so the packet has been retransmitted through an alternative 863 destination), the exit path used is stored in the Exit Path Cache and 864 following packets are sent through the same exit path. Exit Path 865 Cache entries have a finite lifetime. An Exit Path Cache entry 866 lifetime is extended every time that a packet is received coming from 867 the corresponding exit path. When an Exit Path Cache entry lifetime 868 expires, the failure detection procedure is performed when new 869 packets arrive for such destination. 871 A case that has to be considered is when no reply packets for a given 872 destination are received from any exit path. Such behavior may have 873 two causes: the application generates unidirectional traffic, so no 874 packets are supposed to arrive or all the paths are down. In any of 875 the two cases the mechanism can't do anything to select the exit 876 path, so when such situation is detected, a random exit path has to 877 be selected and used. So, an Exit Path Cache entry is generated with 878 a random path and with a certain lifetime. When the lifetime expires, 879 the failure detection mechanism is performed again, so that if the 880 case was that all exit paths were down, the mechanism can detect when 881 one of the paths is up again. Note that this would cause additional 882 overhead for unidirectional applications, so the failure detection 883 mechanism should not be performed very often i.e. the lifetime should 884 not be very low. 886 5.1.2.3 Hybrid approach: Routing system based failure detection and host 887 based exit path selection 889 An alternative approach is to obtain the information about available 890 paths from the routing system but let the host to force the routing 891 of packets through the identified exit path. The benefit of this 892 approach is that the routing information injection into the 893 intra-site routing system is not required because the exit path is 894 selected by the host. 896 This hybrid approach requires a mechanism to convey the path 897 availability information from the routing system to the hosts. 898 Considering the amount of information involved, we consider that it 899 is better to limit the path information stored in the hosts to the 900 information concerning the paths that the host is currently using. 901 There are two approaches that can be used at this point. 903 One possible approach is to define a new protocol to let the host to 904 query a server for the correct exit path to be used to reach a 905 certain destination, for example as defined in [16]. The server would 906 have to be configured with enough information to answer those 907 queries. For instance the server has to know all the BGP information 908 that is received from each one of the ISPs, the associated prefix and 909 the address of the corresponding exit router. So, when a host wants 910 to initiate a communication with an unknown destination address, it 911 queries the server and obtains the exit path to be used. Then the 912 host itself forces the packet to be routed through the exit path. 914 An alternative option is to let the exit routers to inform the host 915 about the correct exit path to be used. In this case, only the exit 916 routers are running BGP. So, when a host sends a packet to a new 917 destination, it randomly selects the exit path. More likely, the host 918 will randomly select a source address and won't tunnel the packet, so 919 that the packet is carried to the default route. In case that the 920 destination contained in the packet is not reachable through the ISP 921 whose prefix has been included as source address, but the exit router 922 knows because of BGP that it is reachable through an alternative exit 923 router, the exit router will send an ICMP error message containing 924 the exit path information back to the host. 926 A particular case of this approach can be used when the failure has 927 occurred in the direct link. In this case, the exit router can detect 928 the outage and considering that no destination is reachable through 929 this ISP, simply deprecate the prefix. This approach is only an 930 optimization since it does not address the general case. 932 5.2 Preserving established communications 934 Multiple solutions for preserving established communications have 935 been proposed such as HIP, SIM, ODT, LIN6, MAST, NOID, CB64. Many of 936 these approaches mainly focus on how to present an unchanged IP 937 address to the upper layers through changes in the address used to 938 actually reach the host. However, not only such mechanism is required 939 in order to preserve established communications, but a mechanism to 940 perform path selection is also required (both a mechanism to identify 941 available paths and a mechanism to force the routing of packets 942 through the identified path are required). Additionally, a mechanism 943 to solve the site exit issue may be needed in those solutions. 945 Next versions of this document will include an analysis of which 946 mechanism can be used to select paths during the lifetime of a 947 communication and how such mechanisms can interoperate with the 948 proposed solutions. 950 6. Integrating Solutions 952 In this section we will integrate solutions, combining a site exit 953 issue solution with a path selection solution. Next, we will present 954 what we consider to be the most natural combinations of a solution 955 for the site exit issue and an exit path selection mechanism. Other 956 combinations may be possible but they don't seem very natural so far. 957 Perhaps future versions of this document will consider them if it 958 seems appropriate. 960 6.1 Solution 1: Relaxing source address checks + Intra site routing 961 system based exit path selection 963 The site exit issue is addressed relaxing the source address checks 964 at the ISP, since the required level of trust exists between the site 965 and the ISPs. The exit path selection is addressed using BGP and 966 injecting some of the information into the intra-site routing system. 967 Since BGP expertise is available, appropriate filters can be 968 configured. 970 Requirements: 972 - enough level of trust between the site and the ISPs in order to 973 relax the source address check 975 - enough expertise to run BGP and configure appropriate filters 977 - enough resources to import part of the global routing table into 978 intra-site routing system 980 Suitable for: big/medium sites. The solution is not deemed suitable 981 for small sites because of the required level of expertise and 982 resources. 984 6.2 Solution 2: Source address Discovery + Intra site routing system 985 based exit path selection 987 The host generates packet with one if its source address and then the 988 packet is routed according the information available at the 989 intra-site routing. When the packet reaches the site border router, 990 it verifies the source address. If the source address is compatible 991 with the selected ISP, the packet is forwarded as it is, if not, the 992 exit router discards the packet and sends an ICMP Destination 993 Unreachable error message (code 5) back to host informing the 994 appropriate source address for the selected destination. 996 Requirements: 998 - enough expertise to run BGP and configure appropriate filters 1000 - enough resources to import part of the global routing table into 1001 intra-site routing system 1003 - Required modifications: all hosts within the multihomed site have 1004 to be modified to implement the processing of the ICMP error in order 1005 to work properly. Communications initiated by hosts within the 1006 multihomed not implementing such processing will fail when selecting 1007 the wrong source address. Those hosts will not obtain even the level 1008 of service they would obtain in a single homed site. 1010 Suitable for: big/medium sites The solution is not deemed suitable 1011 for small sites because of the required level of expertise and 1012 resources. 1014 6.3 Solution 3: Packet Rewriting at site exit + Intra site routing 1015 system based exit path selection 1017 The host generates packet with one of its source address and then the 1018 packet is routed according the information available at the 1019 intra-site routing. When the packet reaches the site border router, 1020 it verifies the source address. If the source address is compatible 1021 with the selected ISP, the packet is forwarded as it is, if not, the 1022 exit router rewrites the source address of the packet with a new 1023 prefix compatible with the exit ISP. 1025 Requirements: 1027 - enough expertise to run BGP and configure appropriate filters 1029 - enough resources to import part of the global routing table into 1030 intra-site routing system 1032 - Required modifications: all hosts within the multihomed site have 1033 to be modified to implement a mechanism to recognize reply packets 1034 with modified destination address as valid replies to the initial 1035 packet. Communications initiated by hosts within the multihomed site 1036 not implementing such mechanism will fail when using a source address 1037 that is rewritten at site exit. Those hosts will not obtain even the 1038 level of service they would obtain in a single homed site. Additional 1039 modification in applications and/or external hosts may be required. 1041 Suitable for: big/medium sites The solution is not deemed suitable 1042 for small sites because of the required level of expertise and 1043 resources. 1045 6.4 Solution 4: Host based exit path selection + source address based 1046 routing 1048 In this case, an exit path is determined by the source address 1049 selected included in the packet. So, the host can force the routing 1050 of a packet through an exit path just by selecting the source 1051 address. So, the host determines which paths are available by sending 1052 packets with different source addresses. If reply packets arrive, the 1053 path associated with the destination address included in the reply 1054 packet is available, so the address is introduced in the site exit 1055 path cache. 1057 Requirements: 1059 - Configuration of source address dependent routing. This can be 1060 configured site wide or just at the site exit routers. In the second 1061 case, a mesh of tunnels between of the site exit router has also to 1062 be configured 1064 - Required modifications: implementation of the path discovery 1065 mechanism in the hosts of the multihomed site in order to benefit 1066 from multihoming. Hosts not implementing such mechanism can configure 1067 a single source address and behave as they were in a single homed 1068 site. Source address dependent routing is supported by some router 1069 vendor. 1071 Suitable for: small sites While this solution may be adopted by 1072 medium and big sites, those sites may prefer other type of solutions 1073 based on BGP because policy issues. This solutions relies on hosts to 1074 implement policing, since the hosts themselves perform the path 1075 selection. Other solutions based on BGP enable policy configuration 1076 on router or in central servers. This last option is considered to be 1077 more scalable with respect to the number of hosts within the site, 1078 making it more attractive for medium and big sites. 1080 6.5 Solution 5: Host based exit path selection + site exit discovery 1082 In this case, hosts within the multihomed site tries to discover the 1083 available exit path by generating packets with different source 1084 address. In the case that the exit ISP corresponds to the selected 1085 source address, the packet is forwarded through the ISP. If not, the 1086 packet is discarded and an ICMP error message containing the 1087 appropriate exit router is sent back to the host. The host then 1088 retries forcing the routing of the packet, tunneling it directly to 1089 the exit router. The host identifies available paths when it receives 1090 reply packets. The host then stores the information about the source 1091 address and optionally about the exit router to be used in the site 1092 exit path cache. 1094 Requirements: 1096 - Required modifications: implementation of the ICMP error generation 1097 mechanism in the routers. Implementation of the path discovery 1098 mechanism and the processing of the ICMP error in the hosts. 1099 Communications initiated by hosts within the multihomed not 1100 implementing such mechanism will fail when using an incompatible 1101 source address. Those hosts will not obtain even the level of service 1102 they would obtain in a single homed site. 1104 Suitable for: small sites While this solution may be adopted by 1105 medium and big sites, those sites may prefer other type of solutions 1106 based on BGP because policy issues. This solutions relies on hosts to 1107 implement policing, since the hosts themselves perform the path 1108 selection. Other solutions based on BGP enable policy configuration 1109 on router or in central servers. This last option is considered to be 1110 more scalable with respect to the number of hosts within the site, 1111 making it more attractive for medium and big sites. 1113 6.6 Solution 6: Hybrid approach + source address dependent routing 1115 In this case, a server or the exit router has the information about 1116 the correct site exit router and source address to be used for a 1117 given destination. So, the host within the multihomed site contacts 1118 the server and obtains the correct site exit router and the 1119 appropriate source address. Then the hosts sends packets with the 1120 appropriate source address so that it routed trough the correct exit 1121 router, 1123 Requirements: 1125 - enough expertise to run BGP and configure appropriate filters 1127 - enough resources to import part of the global routing table into 1128 intra-site routing system 1130 - Required Modifications: the exit router or a server has to inform 1131 the host about the correct source address. So both the router and 1132 hosts has to be modified to implement the mechanism 1134 Suitable for: medium and big sites The solution is not deemed 1135 suitable for small sites because of the required level of expertise. 1137 6.7 Solution 7: Hybrid approach + source address selection by the host 1139 In this case, a server or the exit router has the information about 1140 the correct site exit router and source address to be used for a 1141 given destination. So, the host within the multihomed site contacts 1142 the server and obtains the correct site exit router and the 1143 appropriate source address. Then the host sends packets with the 1144 appropriate source address tunneling it to the correct exit router, 1146 Requirements: 1148 - enough expertise to run BGP and configure appropriate filters 1150 - enough resources to import part of the global routing table into 1151 intra-site routing system 1153 - Required Modifications: the exit router or a server has to inform 1154 the host about the correct exit path. So both the router and hosts 1155 has to be modified to implement the mechanism 1157 Suitable for: medium and big sites The solution is not deemed 1158 suitable for small sites because of the required level of expertise 1159 and resources. 1161 6.8 Remaining combinations 1163 The remaining combinations of site exit issue solutions with site 1164 exit path selections mechanism are considered no to naturally match 1165 together. 1167 For instance, it is considered that sites that obtain the level of 1168 trust required from its provider to relax the source address checks 1169 will prefer to run BGP to obtain the available path information 1170 rather than using a host based or hybrid approach. 1172 In source address dependent routing and in site exit discovery 1173 approaches to the site exit issue, it is the host itself who selects 1174 the exit path (using the source address or tunneling). This type of 1175 mechanism seems hardly compatible with intra-site routing system exit 1176 path selection, since it is no longer the intra-site routing system 1177 that selects the exit path but it is the host through the source 1178 address who performs that selection. 1180 7. Proposed solution 1182 In order to implement the host centric multihoming solution, we must 1183 solve the issues presented in the previous section. In this section, 1184 we will present the recommended ways to solve the site exit issue and 1185 how to trigger rapid reactions to failures. 1187 We will next present different solutions for different scenarios. As 1188 we have concluded from our analysis presented above, different 1189 solutions have different requirements and are then suitable for 1190 different type of scenarios. We will consider three different 1191 scenarios: 1193 - multihoming for small sites 1195 - multihoming for medium sites 1197 - multihoming for big sites 1199 7.1 Multihoming solutions for small sites 1201 It is not likely that small sites can obtain some form of source 1202 address check relaxation from their IPSs, so an alternative solution 1203 to deal with the site exit issue is to be used. It is also considered 1204 that in general, small sites don't have neither the expertise nor the 1205 resources required to run BGP, so an alternative mechanism to react 1206 to topology changes is required. We think that the host based 1207 approach is the mechanism that better suits the requirements of the 1208 small sites. 1210 We will next present a set of mechanism and tools to enable 1211 multihoming is small sites. 1213 The goal is to propose a roadmap to adopt multihoming that preserves 1214 existent functionalities and adds new functionalities progressively. 1215 This would allow legacy systems to keep on working exactly the same 1216 way they did before multihoming adoption and then add new features to 1217 enable multihoming benefits 1219 7.1.1 Step 1: preserving functionality for legacy hosts when becoming 1220 multihomed. 1222 Suppose that a single homed site becomes multihomed. The problem here 1223 is that the site exit issue will affect communications of the newly 1224 multihomed site. So, the first step is to deploy a solution for the 1225 site exit issue as simple as possible that does not require updating 1226 the hosts of the site, and if possible does not requires updating 1227 other equipment. Using such solution, legacy hosts within the 1228 multihomed site will work as if they were in a singlehomed site. That 1229 is, they will not obtain multihoming benefits, but at least they will 1230 not fail because of multihoming. This solution also allows then 1231 attaching legacy hosts to the site and they will work as if they were 1232 in a singlehomed site. 1234 In line with the analysis presented in the previous section, our 1235 recommendation is to enable multihoming by establishing tunnels 1236 between the site exit routers. In order to implement this solution, 1237 we must define a way to convey the site exit addresses to the various 1238 routers in the site; the simplest solution, which we propose here, 1239 uses an anycast address that is arithmetically derived from the 1240 sites' prefixes. 1242 7.1.1.1 Site exit anycast address 1244 The site exit anycast address solution assumes that all of the sites 1245 prefixes have the same length L; it also assume that we can define a 1246 conventional "subnet" associated to the prefix. The proposed solution 1247 is to compose the anycast address by appending an "all 1" suffix to 1248 the site prefix: 1250 <----- L bits -----> <---- 128 - L bits -----> 1251 +-------------------+-------------------------+ 1252 | Valid site prefix | 1111...............1111 | 1253 +-------------------+-------------------------+ 1255 -- Site exit anycast address -- 1257 Each site exit router that can forward to the outside packets whose 1258 source address is derived from a specific site prefix will advertise 1259 reachability of the corresponding site exit anycast address through 1260 the routing mechanism. 1262 7.1.1.2 Tunneling to the appropriate exit 1264 Site exit routers are expected to perform necessary source address 1265 checks before forwarding any packet on a site exit link. The site 1266 exit router must check the source address first, in order to avoid 1267 local packets being routed to a black hole. If the result of the 1268 check is positive, the packet will be forwarded. If the result is 1269 negative, the router will derive a "site exit anycast address" from 1270 the source address of the incoming packet. If the anycast address is 1271 unreachable, the incoming packet will have to be discarded. If the 1272 anycast address is reachable, the incoming packet will be tunneled 1273 towards that address. 1275 It is accepted that tunneling mechanism introduces additional 1276 overhead, but it is recommended because its fast deployability. 1277 However, in the long run, a mechanism based on source address 1278 dependent routing will provide better performance. Such mechanism can 1279 be gradually deployed as presented in section 4.2 1281 7.1.2 Step 2: Optimizations to enhance the multihoming support 1283 7.1.2.1 Site exit router discovery 1285 A problem with the approach presented in the previous section is that 1286 packets may be routed through a suboptimal path, because they are 1287 initially routed towards a site exit router and if the source address 1288 doesn't match, this site exit will send the packet through a tunnel 1289 to an alternative exit router. This problem can be solved using a 1290 Site Exit Redirection ICMP message. This ICMP error would be 1291 generated by the site exit routers when they receive a packet whose 1292 source address doesn't match with the exit ISP. So, after forwarding 1293 the packet through a tunnel to the appropriate site exit, the router 1294 generates a Site Exit Redirection ICMP message to inform the 1295 originating host about the correct site exit router for this 1296 destination and source address combination. 1298 7.1.2.1.1 Site Exit Redirection ICMP message 1300 Routers send site exit redirect packets to inform a host of a better 1301 exit path on the path to a destination. 1303 0 1 2 3 1304 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | Type | Code | Checksum | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 | Source prefix length | Redirection life time | 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 | | 1311 + + 1312 | | 1313 + Site Exit Address + 1314 | | 1315 + + 1316 | | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 | Options ... 1319 +-+-+-+-+-+-+-+-+-+-+-+- 1320 IP Fields: 1322 Source Address: An address assigned to the router from which this 1323 message is sent. 1325 Destination Address: The Source Address of the packet that triggered 1326 the redirect. 1328 Hop Limit: 255 1330 Authentication Header: If a Security Association for the IP 1331 Authentication Header exists between the sender and the destination 1332 address, then the sender SHOULD include this header. 1334 ICMP Fields: 1336 Type: TBD, IANA 1338 Code: 0 1340 Checksum: The ICMP checksum. See [14]. 1342 Prefix length: The length of the source address prefix, in bits, 1343 expressed as a 16 bit integer, transmitted in network order, i.e. 1344 most significant byte first. 1346 Redirection lifetime: The number of seconds during which the 1347 redirection should remain in effect, expressed as a 16 bit integer, 1348 in network byte order. 1350 Site Exit Address: An IP address of the preferred exit router to use 1351 for packets sent using as source address the IPv6 destination of this 1352 packet, or using any source address whose prefix matches the first 1353 "prefix length" bits of this packet's IPv6 destination. 1355 Possible options: 1357 Redirected Header: As much as possible of the IP packet that 1358 triggered the sending of the Redirect without making the redirect 1359 packet exceed 1280 octets. 1361 7.1.2.1.2 Host behavior 1363 Hosts can be programmed to perform "exit router discovery", i.e. 1364 associate to a source and destination address pair the address of the 1365 preferred exit router, and then tunnel packets directly to that exit 1366 router. Hosts will learn the address of the exit router through ICMP 1367 "Site Exit Redirection" messages. 1369 Any redirection message poses a potential threat, since it can be 1370 used by third parties to misdirect and possibly capture traffic. In a 1371 secure set-up, hosts will establish a security association with the 1372 exit routers, and will only accept Site Exit Redirection messages 1373 that are properly secured by an authentication header. In the absence 1374 of a security association, the host may perform a number of checks 1375 before accepting a Site Exit Redirection ICMP message: 1377 * check that the IPv6 source address corresponds to a local prefix; 1379 * check that the prefix length has a realistic value, e.g. at least 1380 48 bits; 1382 * check that the Site Exit Address matches the site prefix being 1383 redirected; 1385 * select a redirection life time that is the minimum of the ICMP 1386 value and a locally selected maximum duration. 1388 Since site exit discovery is a routing optimization, hosts should 1389 balance the routing gain with the possible security risk. 1391 7.1.2.2 Rapid reaction to failures 1393 7.1.2.2.1 Direct link failures 1395 In order to react to local failures, we must establish a 1396 communication channel that quickly signals these failures to the 1397 hosts. The logical channel to use is the "router advertisement" 1398 message, which the routers use to communicate to hosts the list of 1399 available prefixes. We propose here to use the "preferred" and 1400 "valid" flags in these prefixes to signal to hosts the addresses that 1401 should, or should not, be used as source address at any given time. 1403 This solution is sufficient when the site is composed of a single 1404 link; for more complex site, we propose to use the "router 1405 renumbering" mechanism to maintain an up-to-date list of available 1406 prefixes. 1408 7.1.2.2.1.1 Use of Router advertisements 1410 The router advertisement messages are defined in [3]; their use for 1411 address configuration is defined in [4]. As specified in [3], the 1412 router advertisements include a variable number of Prefix Information 1413 parameters. Each Prefix Information parameter specifies: 1415 * an address prefix value, 1416 * an "on-link" flag, used in neighbor discovery, 1418 * an "autonomous" flag, used for autonomous address configuration, 1420 * the "valid" lifetime, 1422 * the "preferred" lifetime. 1424 We propose to use the "preferred" lifetime to indicate whether 1425 addresses derived from the prefix can be used as source address in 1426 multihomed networks. When a prefix is temporarily not available 1427 routers MUST advertise a null preferred lifetime for that prefix. 1429 In conformance with section 5.5.4 of [3], the hosts will notice that 1430 the formerly preferred address becomes deprecated when its preferred 1431 lifetime expires. They will not use the deprecated addresses in new 1432 communications if an alternate (non-deprecated) address is available 1433 and has sufficient scope. 1435 Manipulating the preferred lifetime only solves part of our problem, 1436 since according to [3] the hosts should continue to use the "valid" 1437 source address in existing communications. To actually maintain the 1438 transport sessions that used the now unavailable link, we will need 1439 additional host improvements. 1441 7.1.2.2.1.2 Use of Router Renumbering 1443 In order to advertise a null preferred lifetime for a specific 1444 prefix, the sites routers must be able to learn about that prefix. A 1445 possibility is to use the "Router renumbering" protocol [6][RFC2894] 1446 to pass this information. The protocol allows an authorized agent, in 1447 that case the egress site, to update the list of prefixes advertised 1448 by the site's routers. The protocol can be used to change parameters 1449 associated to a prefix, such as the preferred lifetime. 1451 7.1.2.2.2 Reaction to other failures modes 1453 Based on the analysis presented in section 5 and 6, we recommend the 1454 adoption of a host based exit path selection mechanism to enable the 1455 hosts within the multihoming site to react to topology changes. 1457 Considering that we are recommending a solution for the site exit 1458 issue based on source address dependent routing, we can assume that 1459 the exit ISP is determined by the source address included in the 1460 packet. So, in order to force the routing of a packet through a 1461 particular ISP, the host only has to set the appropriate source 1462 address. As described in section 5, the proposed mechanism to 1463 identify available paths will be based on the trial and error 1464 procedure. 1466 The following mechanism is to be implemented in host in order to 1467 react to topology changes. 1469 7.1.2.2.2.1 Exit Path Cache 1471 An Exit Path Cache is created in the hosts. Each entry contain for a 1472 Destination Address, information about the corresponding Source 1473 Address and a lifetime. 1475 Exit Path Cache entry creation process: 1477 When the host receives a packet containing a Source Address SA and a 1478 Destination Address DA, the Exit Path Cache is searched for an entry 1479 that contains SA Destination Address field. 1481 - If such entry is found, the Source Address is verified. 1483 -- If the Source Address contains DA, then the lifetime of the entry 1484 is extended. 1486 -- If the Source Address is other than DA, then the cache entry is 1487 updated and DA is stored in the Source Address field. The lifetime of 1488 the entry is extended. (would this break some apps?) 1490 - If the entry is not found, the entry is created, with SA as the 1491 Destination Address and DA as the Source Address. The entry is 1492 blocked from changes for a certain period to avoid that multiple 1493 answers used in the next section produce suboptimal behavior. (the 1494 other option would be not to modify existent (valid) cache entries 1495 when packets with a different DA are received) 1497 7.1.2.2.2.2 Initiating new communications 1499 When a host attempts to initiate a communication with a certain 1500 destination address D, it first verifies if an Exit Path Cache entry 1501 exists for that destination address D. If it does exists, the host 1502 obtains the source address to be used form it. 1504 If no entry exists for that destination address D, the host generates 1505 multiple packets, one per available source address, sends them and 1506 sets a timer. 1508 If a reply packet is received, the cache entry is created as 1509 described in the previous section. Following packets addressed to 1510 that destination will use the discovered source address if the 1511 applications does not sets the source address to be used. 1513 If the timer expires before any packets containing D as source 1514 address are received, this may mean that there is no exit path 1515 available to reach destination D or that the application generates an 1516 unidirectional flow, so no packets are to be received. In any case, 1517 the issue cannot be addressed at this level, so the recommended 1518 behavior is that the host simply selects one source address S and use 1519 it for the packets addressed to destination D. In order to avoid the 1520 procedure to restart, a Exit Path Cache entry has to be created for 1521 this destination address, containing the selected source address. 1523 7.1.2.2.2.3 Preserving established communications 1525 TBD 1527 7.2 Multihoming solution for medium sites 1529 Medium sites are likely to be capable of running BGP but they may not 1530 be able to obtain enough trust from their ISP to relax the source 1531 address checks. So, medium sites could use the mechanisms proposed 1532 for small sites, but they are likely to benefit by integrating BGP in 1533 the multihoming solution. 1535 So, the recommended integration of BGP capabilities in the proposed 1536 small site solution basically affects the mechanism used to react to 1537 topology changes affecting non-direct links. 1539 This means that the solution for the site exit issue recommended for 1540 medium sites is also a mesh of tunnels as presented in section 7.2.1 1541 allowing a smooth transition to multihoming without interfering with 1542 the installed base within the multihomed site. Also, we recommend the 1543 usage of Neighbor Advertisement and Neighbor Renumbering to convey 1544 information about direct link outages by deprecating the 1545 correspondent prefix, as presented in section 7.2.2.1.1. 1547 7.2.1 Reaction to topology changes 1549 The proposed solution requires that the site exit routers run BGP 1550 with their correspondent providers. By doing so, exit router have 1551 information about reachable destinations through their directly 1552 connected ISP. Moreover, through IBGP sessions with the other site 1553 exit routers, they have information about reachable destination 1554 through the other ISPs. 1556 An Exit Path Cache is created in the hosts. Each entry contains for 1557 each Destination Address, information about the corresponding Source 1558 Address and a lifetime. 1560 Exit path Cache entries are created when the host receives a packet 1561 as described in section 7.2.2.1.2.1 1563 So when a host attempts to initiate a communication with a certain 1564 destination address D, it first verifies if an Exit Path Cache entry 1565 exists for that destination address D. If it does exist, the host 1566 obtains the source address to be used from it. 1568 If no entry exists for that destination address D, the host just 1569 selects one of the possible source addresses and includes it in the 1570 packet. 1572 When the packet reaches the site exit router the following situations 1573 are possible: 1575 1. The destination is reachable through this site exit router and its 1576 directly connected ISP and the source address contains the prefix 1577 corresponding to the connected ISP. In this case, the site router 1578 forwards the packet through its directly connected ISP. 1580 2. The source address contained in the packet corresponds to another 1581 exit router and the destination is reachable through the other site 1582 exit router (the one that corresponds to the source address). In this 1583 case, the router tunnels the packet to the correct site exit router 1584 and sends a Site Exit Redirection ICMP message (as defined in 1585 7.2.2.1.1) back to the host, so that the host can send following 1586 packets directly to the correct exit router. 1588 3. The destination is not reachable through the ISP that corresponds 1589 to the source address included in the packet, but it is reachable 1590 through another ISP. In this case, this packet has to be discarded 1591 and the host has to be informed that an alternative source address 1592 has to be used. The router then sends an ICMP Destination Unreachable 1593 Error message with code 5 (meaning source address failed ingress 1594 policy) back to the host, carrying in the source address the prefix 1595 that has to be used to reach the selected destination. A new Exit 1596 Path Cache entry is created containing the source and destination 1597 address. 1599 4. The destination is unreachable through any of the ISPs, so the 1600 packet is discarded and an ICMP Destination Unreachable error message 1601 is sent back to the host. 1603 7.3 Multihoming solution for big sites 1605 A big site is likely to have enough expertise and resources available 1606 to run BGP. Also, it seems likely that a big site can obtain the 1607 required level of trust from its providers to relax the source 1608 address checks. So, big sites are likely to adopt a multihoming 1609 solution based on these two mechanisms, the relaxation of source 1610 address checks and the usage of BGP and the intra-site routing system 1611 to select the exit path. 1613 Source address check relaxation allows a big site to become 1614 multi-homing without prejudice to legacy hosts within the multi-homed 1615 site. Those hosts can still work properly as if they were in a single 1616 homed site. 1618 BGP provides information about what path reaches the selected 1619 destination. However, in case that one of the ISPs is down, the 1620 corresponding address is unreachable, meaning that such address is 1621 not to be used as a source address by hosts within the multihomed 1622 site that establish new communications, because there is no route 1623 available for return packets. In this case, a similar (but 1624 simplified) mechanism to the one proposed in the previous section 1625 about reaction to topology changes for medium sites is to be used. 1626 This mechanism is simpler because no ingress filtering considerations 1627 are involved, so the situation described in point 2 in the section 1628 above is no longer relevant. 1630 8. Evaluation of Host centric solution and Multihoming Goals 1632 The MULTI6 working group has elaborated a list of goals for a 1633 multi-homing solution that is detailed in [7]. In this section, we 1634 will review how the host centric approach to IPv6 multihoming meets 1635 these goals, which are distributed in two subsections: matching the 1636 capabilities of IPv4 multihoming, and meeting additional goals. 1638 8.1 Capabilities of IPv4 Multihoming 1640 8.1.1 Redundancy 1642 The solution presented here can provide protection against: 1644 o Physical link failure, 1646 o Logical link failure, 1648 o Routing protocol failure, 1650 o Transit provider failure, and 1652 o Exchange failure. 1654 Basic redundancy is provided by the availability of multiple 1655 addresses, that can be tried in turn, and by a reliance on classic 1656 destination based routing protocols. We assume that if an address is 1657 reachable, the routing protocol will find a path that leads to it; at 1658 worst, the host will have to perform several transmission trials, 1659 using different addresses, until the destination is reached. 1661 On the reverse path, redundancy is based on the selection of an 1662 appropriate source address. The "preferred lifetime" mechanism allows 1663 even the simplest hosts to learn which addresses are robust enough to 1664 be used. 1666 Destination and source selection provide a protection against a 1667 failure of the site access link, which is catalogued in the goals as 1668 Physical link failure, or Logical link failure. The availability of 1669 multiple destination addresses provides a protection against Routing 1670 protocol failure, Transit provider failure, and Exchange failure on 1671 the forward path: the communication will succeed if at least one of 1672 the destination addresses can be routed. The protection against such 1673 failures on the reverse path is provided if multiple source addresses 1674 are tried. 1676 8.1.2 Load Sharing 1678 An enterprise can distribute the inbound traffic by manipulating the 1679 "preference" associated to various addresses in the DNS, e.g. by 1680 using mechanisms such as MX records or SRV records. 1682 8.1.3 Performance 1684 Performance enhancements can be obtained by appropriate development 1685 of destination address selection and source address selection 1686 algorithms. 1688 8.1.4 Policy 1690 Classes of applications may be shifted to a specific provider by 1691 appropriate use of DNS records associated to specific services. For 1692 example, the NNTP traffic could be directed to the specific server 1693 "nntp.example.com", and the enterprise could decide to only advertise 1694 for that server an address provided by one of its providers. 1696 The Policy table defined in [15] allows to prefer a certain source 1697 address rather than others. Considering that the source address 1698 determines the exit path, the policy table allows to express the 1699 preferred exit path. 1701 8.1.5 Simplicity 1703 Host centric multihoming is simple to deploy, since it does not 1704 require any cooperation between the site and its providers, or in 1705 fact between the various providers. The main requirement is to 1706 advertise an up-to-date list of prefixes in the router 1707 advertisements; this can be automated using the router renumbering 1708 protocol. 1710 8.1.6 Transport-Layer Survivability 1712 TBD 1714 8.2 Additional Goals 1716 8.2.1 Scalability 1718 The host centric multihoming system does not impose any unreasonable 1719 requirements on the routing system: the sites use multiple addresses, 1720 but each of these addresses can be aggregated under the prefixes of 1721 their respective providers. 1723 8.2.2 Impact on Routers 1725 In order to quickly signal to hosts any change in the sites' 1726 connectivity, the site routers should implement the "router 1727 renumbering" procedures, and the exit routers should be able to use 1728 that procedure if a physical or logical link becomes unavailable. 1729 Additionally, routers have to implement the new Site Exit redirection 1730 ICMP message and the proposed processing of the ICMP destination 1731 unreachable error message with code 5 (source address failed ingress 1732 policy). 1734 8.2.3 Impact on Hosts 1736 The solution does not destroy IPv6 connectivity for a legacy host 1737 implementing [1], [2], [5] and other basic IPv6 specifications 1738 current in January 2004. Such hosts may not be taking the full 1739 benefit from multihoming; in particular, their transport connections 1740 may not survive the failure of a site connection. However, the 1741 preferred lifetime mechanism guarantees that after a re- homing 1742 event, the new connections of these basic hosts will follow an 1743 available path. 1745 Hosts will take better advantage of multi-homing if they implement 1746 better destination address and source address selection algorithms, 1747 exit router discovery. Each of these is a logically separate function 1748 that can be added to existing functions. 1750 The solution does not require changes to the socket API and/or the 1751 transport layer; such changes may however be required if the host 1752 wants to implement a combined selection of the source and destination 1753 addresses, which is an optional additional function. The solution 1754 allows host or application change to enhance session survivability. 1756 8.2.4 Interaction between Hosts and the Routing System 1758 The interaction between a site's hosts and its routing system is 1759 limited to the normal processing of router advertisements. 1761 Upgraded host will be able to obtain additional information from the 1762 routing system through the newly defined ICMP messages. 1764 8.2.5 Operations and Management 1766 It is possible to monitor and configure the multihoming system. 1768 9. Things MULTI6 Developers should think about 1770 This section contains the answers to the questions contained in [17]. 1772 9.1 The Answers 1774 9.1.1 Routing 1776 9.1.1.1 How will your solution solve the multihoming problem? 1778 The Host-Centric Multihomig proposal addresses multiple of the 1779 multihoming issues. In particular, Host Centric multihoming proposal 1780 includes mechanisms to: 1782 - Solve the site exit issue 1784 - Select proper (reachable) addresses when establishing a 1785 communication 1787 - Perform policing 1789 The Host Centric multihoming proposal does not includes a proposal to 1790 preserve established communications through outages. However, The 1791 compatibility of Host Centric multihoming mechanisms with proposed 1792 solution to provide transport layer connection survivability will be 1793 analysed in future versions of the document. 1795 9.1.1.2 Uniqueness 1797 9.1.1.2.1 Does your solution address mobility? 1799 No. 1801 9.1.2 Identifiers and locators 1803 9.1.2.1 Does your solution provide for a split between identifiers and 1804 locators? 1806 No. 1808 9.1.3 On The Wire 1810 9.1.3.1 At what layer is your solution applied, and how? 1812 All the proposed mechanisms work at the IP layer. 1814 Is it applied in every packet? 1815 No. 1817 If so, what fields are used? 1819 Some packets may require to be tunneled to the correct exit router, 1820 so an additional IPv6 header may be required. 1822 9.1.3.2 Why is the layer you chose the correct one? 1824 Host Centric Multihoming basically uses tools that are already 1825 available in some form in current implementations. While some 1826 modifications are required, the goal is to reuse as much of the 1827 existent mechanisms as possible. So, the layer used is the layer 1828 where these mechanisms already reside. 1830 9.1.3.3 Does your solution expand the size of an IP packet? 1832 The solution does not expand the size of the packet but is uses 1833 tunnels in some occasions, so we will analyze the impact of tunnels 1834 in fragmentation in this section. 1836 Some packets require to be tunneled to the correct tunnel. Two type 1837 of tunneling is used: 1839 - Tunnels between the site exit routers: when packets reach the exit 1840 router selected by the intra-site routing system, the exit router 1841 verifies whether the source address is compatible with ingress 1842 filtering defined by the directly connected provider. If not, the 1843 packet will be tunneled to the appropriate exit router. Such 1844 tunnelling imposes a reduced MTU. There are two was this can be 1845 handled. One option could be to announce a reduced MTU within the 1846 site, so that hosts just assume a 20 bytes smaller MTUs always and 1847 tunnel overhead doesn't impose additional fragmentation. The other 1848 option would be just to let the tunnel endpoint to fragment when 1849 needed. 1851 - Tunnels between the host and the site exit router: when the host 1852 learns the appropriate exit router through the ICMP Site exit 1853 redirection message, the host will tunnel packet directly to the exit 1854 router. Again, in this case the host may need to fragment the packets 1855 because of the tunnel overhead. It should be noted that packets will 1856 only be tunnelled once, whether between exit router or from the host 1857 to the exit router. In no case a packet will be tunneled twice 1858 because of the multihoming solution. Now, if the option to announce a 1859 20 byte smaller MTU within the site is adopted, it would be 1860 desirable that also the tunnels between the host and the exit router 1861 can use this reserved space. So an option could be to present the 1862 smaller MTU to the upper layers, but allow the tunnel interface to 1863 send 20 bytes larger packets. 1865 Summarizing, the solution will imply a 20 byte MTU reduction within 1866 the multihomed site. 1868 This overhead can be eliminated by adopting a source address 1869 dependent routing within the site. 1871 9.1.3.4 Will your solution add additional latency? 1873 Small sites: two strategies for detecting available path when 1874 initiating communications are presented: sequential retrial of paths 1875 or path retrial in parallel. The first approach would impose and 1876 additional latency in the case that the first path is not available. 1877 The second option would introduce packet overhead but would not 1878 increase the latency. 1880 Medium and Big sites: in this case, site exit router will have the 1881 information about destination address reachability. In the case that 1882 the destination address is not reachable through the ISP 1883 corresponding to the selected source address, the packet will be 1884 discarded and an increased latency will be generated. However, the 1885 introduced latency will reduced since the packet is discarded within 1886 the site. 1888 9.1.3.5 Do you change the way fragmenting is handled? 1890 No, see above. 1892 9.1.3.6 Are there any changes to ICMP error semantics? 1894 A new Site Exit redirection ICMP message is defined. see section 1895 7.2.2.1 1897 The processing of the ICMP destination unreachable error message with 1898 code 5 (source address failed ingress policy) will be modified 1899 according to the procedure described in section 4.3 1901 9.1.4 Names, Hosts, Endpoints, or none of the above? 1903 9.1.4.1 Please explain the relationship of your solution to DNS 1905 Host Centric Multihoming does not introduce a new namespace nor 1906 separates locators from identifiers. No changes to the DNS are 1907 introduced. 1909 9.1.4.2 If you are not using DNS... 1911 No other mechanism is used. 1913 9.1.4.3 Please explain interactions with 2-faced DNS 1915 No changes are introduced to the DNS. 1917 9.1.4.4 Does your solution require centralized registration? 1919 No. 1921 9.1.4.5 Have you checked for DNS circular dependencies? 1923 No changes are introduced to the DNS. 1925 9.1.4.6 How does a host know its identity? 1927 No new identity is defined. The host learns its IP address by 1928 existent mechanisms. 1930 9.1.4.7 What if a DNS server itself is multihomed? 1932 Host Centric Multihomed can be used to provide multihoming benefits 1933 DNS. In order to benefit from multihoming, the DNS server has to 1934 implement the host mechanisms, just as any other host within the 1935 multihomed site that benefits from Host Centric Multihoming. 1937 9.1.4.8 What additional load will be placed on DNS servers? 1939 None. 1941 9.1.4.9 Any upstream provider support required? 1943 for small sites: none 1945 For medium sites: running BGP with the site 1947 For big sites: relaxing ingress filtering, running BGP with the site 1949 9.1.4.10 What application/API changes are needed? 1951 None. It is assumed that current applications are RFC 3484 compliant 1953 9.1.4.11 Is this solution backward compatible with old IP version 6? 1955 Yes. 1957 Can it be deployed incrementally? Please describe how. 1959 Incremental deployment is the major goal of the Host Centric 1960 Multihoming proposal. In order to enable incremental deployment, the 1961 following roadmap is proposed: 1963 1- The first step is to preserve at least single homing 1964 functionalities when a single homed host that becomes multihomed. 1965 When a single site becomes multihomed, the site exit issue affects 1966 the communications of the hosts of the newly multihomed site. 1967 Establishing a mesh of tunnels between the site exit router in the 1968 case of the small and medium sites and relaxing the source address 1969 checks in the big sites overcomes this problems without imposing a 1970 general equipment upgrade. Moreover, the proposed solution only 1971 requires configuration of the specific devices. After this step, all 1972 the hosts within the multihomed site will work at least as if they 1973 were in a single homed site. 1975 2- The second step is to enable some of the multihoming benefits with 1976 minor modifications. This would provide some degree of fault 1977 tolerance when the direct link between the site and its direct 1978 providers fails. 1980 3- The third step is to enable most of the fault tolerance 1981 capabilities by upgrading the hosts to select the proper path. This 1982 step requires the upgrade of the hosts within the multihomed site. 1984 Does your solution impose requirements on non-multihomed/non-mobile 1985 hosts? 1987 No. The changes required by the solution are limited to the 1988 multihomed site. 1990 What happens if someone plugs in a normal IPv6 node? 1992 The normal IPv6 would work normally in the multihomed site as if it 1993 were in a single homed site and it will also obtain some multihomed 1994 benefits. 1996 9.1.4.12 Is your solution backward compatible with IPv4? 1998 No. The proposed solution only works with IPv6. 2000 9.1.4.13 Can IPv4 devices take advantage of this solution? 2002 No. 2004 9.1.4.14 What is the impact of your solution on different types of 2005 sites? 2007 How are single homed sites impacted? 2009 No impact. 2011 How are small multihomed sites impacted? 2013 The proposed solution for small sites is customized for their special 2014 needs. It doesn't requires complex management (like BGP) nor lot of 2015 resources. It is basically host based and does not requires much 2016 configuration. 2018 How does it scale for large multihomed sites? 2020 For large sites a different solution is presented that requires 2021 additional expertise and resources but enables a higher degree of 2022 centralized control. 2024 What about ad-hoc sites such as an IETF event? 2026 If the hosts are upgraded to support the mechanism used in the 2027 multihomed site, they would obtain the multihomed benefits. If 2028 non-upgraded hosts are connected, they will obtain a service slightly 2029 better than the one offered in a single homed site. 2031 9.1.4.15 How will your solution interact with other middleboxes? 2033 Just as regular IPv6 does. 2035 9.1.4.16 Are there any implications for scoped addressing? 2037 No changes are introduce to the address architecture, so it is 2038 expected that the proposed architecture will interact with scoped 2039 addressing just as regular IPv6. 2041 9.1.4.17 Are there any layer 2 implications to your proposal? 2043 No changes to the interaction with layer two are required. However, 2044 depending on how easily outages are detected, the performance of the 2045 solution may vary. For instance if direct link outages are rapidly 2046 detected, the correspondent prefix will be sooner deprecated and the 2047 performance of the solution will increase. 2049 9.1.4.18 Referrals 2051 Referrals can be handled just as in regular IPv6. However, if 2052 multihoming benefits are expected, the referral should include all of 2053 the IP addresses assigned to the host within the multihomed site, so 2054 that the receiver of the referral can try with the different 2055 addresses in case of failure. 2057 9.1.4.19 What new information should applications be aware of? 2059 None 2061 9.1.4.20 Legal Stuff 2063 None 2065 10. Security Considerations 2067 The use of a site exit redirection ICMP message could potentially be 2068 used to redirect and intercept traffic; secure hosts should only 2069 accept such messages if they are properly authenticated. 2071 11. IANA Considerations 2073 This document requests allocation by IANA of 2 new ICMPv6 message 2074 types. 2076 12. Acknowledgements 2078 This memo incorporates text from a previous draft submitted by 2079 Richard Draves. 2081 We acknowledge Alberto Garcia Martinez, Cedric de Launois, Brian 2082 Carpenter, Dave Crocker and Xiaowei Yang for their reviews and 2083 comments. 2085 References 2087 [1] Hinden, R. and S. Deering, "IP Version 6 Addressing 2088 Architecture", RFC 2373, July 1998. 2090 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 2091 Specification", RFC 2460, December 1998. 2093 [3] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 2094 for IP Version 6 (IPv6)", RFC 2461, December 1998. 2096 [4] Thomson, S. and T. Narten, "IPv6 Stateless Address 2097 Autoconfiguration", RFC 2462, December 1998. 2099 [5] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic 2100 Socket Interface Extensions for IPv6", RFC 2553, March 1999. 2102 [6] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2103 2000. 2105 [7] Abley, J., Black, B. and V. Gill, "Goals for IPv6 2106 Site-Multihoming Architectures", RFC 3582, August 2003. 2108 [8] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 2109 Address Aggregation and Renumbering", RFC 2874, July 2000. 2111 [9] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2112 Defeating Denial of Service Attacks which employ IP Source 2113 Address Spoofing", RFC 2267, January 1998. 2115 [10] Thomson, S. and C. Huitema, "DNS Extensions to support IP 2116 version 6", RFC 1886, December 1995. 2118 [11] Johnson, D., "Mobility support in IPv6", Internet Draft , June 2119 2003. 2121 [12] van Beijnum, I., "BGP", OReilly , 2002. 2123 [13] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2124 Levels", BCP 14, RFC 2119, March 1997. 2126 [14] Conta, A. and S. Deering, "Internet Control Message Protocol 2127 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 2128 Specification", RFC 2463, December 1998. 2130 [15] Draves, R., "Default Address Selection for Internet Protocol 2131 version 6 (IPv6)", RFC 3484, February 2003. 2133 [16] de Launois, C. and O. Bonaventure, "NAROS : Host-Centric IPv6 2134 Multihoming with Traffic Engineering", ID 2135 draft-de-launois-multi6-naros-00.txt, May 2003. 2137 [17] Lear, E., "Things MULTI6 Developers should think about", ID 2138 draft-lear-multi6-things-to-think-about-01, December 2003. 2140 [18] Gupta, M., "Message about new ICMP code points", IPv6 list 2141 message http://www1.ietf.org/mail-archive/working-groups/ipv6/ 2142 current/msg01431.html, February 2004. 2144 Authors' Addresses 2146 Christian Huitema 2147 Microsoft Corporation 2148 One Microsoft Way 2149 Redmond, WA 98052-6399 2150 USA 2152 Phone: 2153 EMail: huitema@microsoft.com 2154 URI: 2156 Richard Draves 2157 Microsoft Corporation 2158 One Microsoft Way 2159 Redmond, WA 98052-6399 2160 USA 2162 Phone: 2163 EMail: richdr@microsoft.com 2164 URI: 2166 Marcelo Bagnulo 2167 Universidad Carlos III de Madrid 2168 Av. Universidad 30 2169 Leganes, Madrid 28911 2170 SPAIN 2172 Phone: 34 91 6249500 2173 EMail: marcelo@it.uc3m.es 2174 URI: http://www.it.uc3m.es 2176 Intellectual Property Statement 2178 The IETF takes no position regarding the validity or scope of any 2179 intellectual property or other rights that might be claimed to 2180 pertain to the implementation or use of the technology described in 2181 this document or the extent to which any license under such rights 2182 might or might not be available; neither does it represent that it 2183 has made any effort to identify any such rights. Information on the 2184 IETF's procedures with respect to rights in standards-track and 2185 standards-related documentation can be found in BCP-11. Copies of 2186 claims of rights made available for publication and any assurances of 2187 licenses to be made available, or the result of an attempt made to 2188 obtain a general license or permission for the use of such 2189 proprietary rights by implementors or users of this specification can 2190 be obtained from the IETF Secretariat. 2192 The IETF invites any interested party to bring to its attention any 2193 copyrights, patents or patent applications, or other proprietary 2194 rights which may cover technology that may be required to practice 2195 this standard. Please address the information to the IETF Executive 2196 Director. 2198 Full Copyright Statement 2200 Copyright (C) The Internet Society (2004). All Rights Reserved. 2202 This document and translations of it may be copied and furnished to 2203 others, and derivative works that comment on or otherwise explain it 2204 or assist in its implementation may be prepared, copied, published 2205 and distributed, in whole or in part, without restriction of any 2206 kind, provided that the above copyright notice and this paragraph are 2207 included on all such copies and derivative works. However, this 2208 document itself may not be modified in any way, such as by removing 2209 the copyright notice or references to the Internet Society or other 2210 Internet organizations, except as needed for the purpose of 2211 developing Internet standards in which case the procedures for 2212 copyrights defined in the Internet Standards process must be 2213 followed, or as required to translate it into languages other than 2214 English. 2216 The limited permissions granted above are perpetual and will not be 2217 revoked by the Internet Society or its successors or assignees. 2219 This document and the information contained herein is provided on an 2220 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2221 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2222 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2223 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2224 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2226 Acknowledgment 2228 Funding for the RFC Editor function is currently provided by the 2229 Internet Society.