Network Working Group C. Huitema Internet-Draft R. Draves Expires: August 10, 2004 Microsoft M. Bagnulo UC3M February 10, 2004 Host-Centric IPv6 Multihoming draft-huitema-multi6-hosts-03 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 10, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract A way to solve the issue of site multihoming is to have a separate site prefix for each connection of the site, and to derive as many addresses for each hosts. This approach to multi-homing, which we call Host-Centric IPv6 Multihoming, has the advantage of minimal impact on the inter-domain routing fabric, since each site prefix can be aggregated within the larger prefix of a specific provider; however, it opens a number of issues, which we will discuss in this memo, including the problem created by the interaction between ingress filtering and multihoming. We then propose a set of specific solutions that enable host centric multihoming, and we review how Huitema, et al. Expires August 10, 2004 [Page 1] Internet-Draft Host-Centric IPv6 Multihoming February 2004 these solutions meet the goals of IPv6 site multihoming. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Notations . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Requirements language . . . . . . . . . . . . . . . . . . . 5 2.2 Reference topology . . . . . . . . . . . . . . . . . . . . . 5 2.3 Site exit router . . . . . . . . . . . . . . . . . . . . . . 5 2.4 Ingress filtering . . . . . . . . . . . . . . . . . . . . . 5 2.5 Site exit anycast identifier . . . . . . . . . . . . . . . . 6 2.6 Site exit anycast address . . . . . . . . . . . . . . . . . 6 3. Host-Centric IPv6 Multihoming issues . . . . . . . . . . . . 7 3.1 Destination address selection . . . . . . . . . . . . . . . 7 3.2 Source address selection . . . . . . . . . . . . . . . . . . 7 3.3 The site exit issue . . . . . . . . . . . . . . . . . . . . 8 3.4 Rapid reaction to topology changes . . . . . . . . . . . . . 9 4. Analysis of solutions to the site exit issue . . . . . . . . 10 4.1 Relaxing the source address checks . . . . . . . . . . . . . 10 4.2 Source address dependent routing . . . . . . . . . . . . . . 11 4.3 Source address selection by the host . . . . . . . . . . . . 13 4.4 Packet rewriting at exit router . . . . . . . . . . . . . . 15 4.5 Comparison of the site exit solutions . . . . . . . . . . . 16 5. Analysis of solutions to provide rapid reaction to topology changes . . . . . . . . . . . . . . . . . . . . . . 18 5.1 Path selection when establishing a new communication . . . . 18 5.1.1 Externally initiated communications . . . . . . . . . . . . 18 5.1.2 Internally initiated communications . . . . . . . . . . . . 18 5.2 Preserving established communications . . . . . . . . . . . 23 6. Integrating Solutions . . . . . . . . . . . . . . . . . . . 24 6.1 Solution 1: Relaxing source address checks + Intra site routing system based exit path selection . . . . . . . . . . 24 6.2 Solution 2: Source address Discovery + Intra site routing system based exit path selection . . . . . . . . . . 24 6.3 Solution 3: Packet Rewriting at site exit + Intra site routing system based exit path selection . . . . . . . . . . 25 6.4 Solution 4: Host based exit path selection + source address based routing . . . . . . . . . . . . . . . . . . . 26 6.5 Solution 5: Host based exit path selection + site exit discovery . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.6 Solution 6: Hybrid approach + source address dependent routing . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.7 Solution 7: Hybrid approach + source address selection by the host . . . . . . . . . . . . . . . . . . . . . . . . 27 6.8 Remaining combinations . . . . . . . . . . . . . . . . . . . 28 7. Proposed solution . . . . . . . . . . . . . . . . . . . . . 29 7.1 Multihoming solutions for small sites . . . . . . . . . . . 29 7.1.1 Step 1: preserving functionality for legacy hosts when Huitema, et al. Expires August 10, 2004 [Page 2] Internet-Draft Host-Centric IPv6 Multihoming February 2004 becoming multihomed. . . . . . . . . . . . . . . . . . . . . 29 7.1.2 Step 2: Optimizations to enhance the multihoming support . . 31 7.2 Multihoming solution for medium sites . . . . . . . . . . . 36 7.2.1 Reaction to topology changes . . . . . . . . . . . . . . . . 36 7.3 Multihoming solution for big sites . . . . . . . . . . . . . 37 8. Evaluation of Host centric solution and Multihoming Goals . 39 8.1 Capabilities of IPv4 Multihoming . . . . . . . . . . . . . . 39 8.1.1 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . 39 8.1.2 Load Sharing . . . . . . . . . . . . . . . . . . . . . . . . 40 8.1.3 Performance . . . . . . . . . . . . . . . . . . . . . . . . 40 8.1.4 Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 8.1.5 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . 40 8.1.6 Transport-Layer Survivability . . . . . . . . . . . . . . . 40 8.2 Additional Goals . . . . . . . . . . . . . . . . . . . . . . 40 8.2.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 40 8.2.2 Impact on Routers . . . . . . . . . . . . . . . . . . . . . 41 8.2.3 Impact on Hosts . . . . . . . . . . . . . . . . . . . . . . 41 8.2.4 Interaction between Hosts and the Routing System . . . . . . 41 8.2.5 Operations and Management . . . . . . . . . . . . . . . . . 41 9. Things MULTI6 Developers should think about . . . . . . . . 42 9.1 The Answers . . . . . . . . . . . . . . . . . . . . . . . . 42 9.1.1 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 42 9.1.2 Identifiers and locators . . . . . . . . . . . . . . . . . . 42 9.1.3 On The Wire . . . . . . . . . . . . . . . . . . . . . . . . 42 9.1.4 Names, Hosts, Endpoints, or none of the above? . . . . . . . 44 10. Security Considerations . . . . . . . . . . . . . . . . . . 49 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 50 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 References . . . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53 Intellectual Property and Copyright Statements . . . . . . . 54 Huitema, et al. Expires August 10, 2004 [Page 3] Internet-Draft Host-Centric IPv6 Multihoming February 2004 1. Introduction There are two basic forms of multihoming, multiple interfaces per host and multiple site connections shared by many hosts. This working group is specifically concerned with site multi-homing. A way to solve the issue of site multihoming is to have a separate site prefix for each connection of the site, and to derive as many addresses for each hosts; this can in fact be supported by a combination of router renumbering (RFC2894) and Stateless Address Autoconfiguration (RFC2462). This approach to multi-homing, which we call Host-Centric IPv6 Multihoming, has the advantage of minimal impact on the inter- domain routing fabric, since each site prefix can be aggregated within the larger prefix of a specific provider; however, it opens a number of issues, which we will discuss in this memo, including the problem created by the interaction between ingress filtering and multihoming. We then propose a set of specific solutions that enable host centric multihoming, and we review how these solutions meet the goals of IPv6 site multihoming. Huitema, et al. Expires August 10, 2004 [Page 4] Internet-Draft Host-Centric IPv6 Multihoming February 2004 2. Notations 2.1 Requirements language In this document, the key words "MAY", "MUST", "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [13]. 2.2 Reference topology In the following discussion, we will use this reference topology: /-- ( A ) ---( ) --- ( C ) --\ X (site X) ( IPv6 ) (Site Y) Y \-- ( B ) ---( ) --- ( D ) --/ The topology features two hosts, X and Y, whose respective sites are both multi-homed. Host X has to global IPv6 addresses, which we will note "A:X" and "B:X", formed by combined the prefixes allocated by ISP A and B to "site X" with the host identifier of X. Similarly, Y has two addresses "C:Y" and "D:Y". We assume that X, when it starts engaging communication with Y, has learned the addresses C:Y and D:Y, for example because they were published in the DNS. We do not assume that the DNS is dynamic: there will be situations in which both C:Y and D:Y are published, while in fact only one is reachable. We assume that Y, when it receives packets from X, has only access to information contained in the packet coming from X, e.g. the source address; we do not assume that Y can retrieve by external means the set of addresses associated to X. 2.3 Site exit router A site exit router is an IPv6 router managing at least one of the connections between a site and the Internet. 2.4 Ingress filtering Ingress filtering refers to the verification of the source address of the IP packets at the periphery of the Internet, typically at the link between a customer and an ISP. This process, which is described in [9] is intended to thwart a class of denial of service attacks in which attackers hide their identity by using a "spoofed" source address. Huitema, et al. Expires August 10, 2004 [Page 5] Internet-Draft Host-Centric IPv6 Multihoming February 2004 2.5 Site exit anycast identifier A 7 bit anycast identifier whose value is XX. [TBD IANA] 2.6 Site exit anycast address An IPv6 anycast address built by combining an IPv6 address prefix allocated to the site with the site exit anycast identifier, according to the rules specified in [RFC2526]. The proposed used of this anycast address is detailed in section 5. Huitema, et al. Expires August 10, 2004 [Page 6] Internet-Draft Host-Centric IPv6 Multihoming February 2004 3. Host-Centric IPv6 Multihoming issues Host-Centric IPv6 Multihoming forces hosts to choose the source and the destination address of the IPv6 packets, in a way that makes the best usage, or at least a reasonable usage, of the network resource. Hosts must first select a destination address, and will then perform source address selection. Source address selection must be consistent with ingress filtering, which is sometime implemented at network interfaces: we call this the "site exit" issue. Destination address selection is often based on incomplete or obsolete information, which can be harmful if, for example, hosts fail to notice that one of the site's connections is suddenly made unavailable. In any case, we must also consider "low budget" hosts, and make sure that these hosts can get some benefits from multihoming without enduring too much cost. 3.1 Destination address selection It is fairly common for hosts to have to choose between multiple destination addresses for a peer. TCP performs this choice when the connection is instantiated; SCTP may perform similar choices through the life-time of the connection; UDP may perform this choice either for each packet, or at the beginning of an association. We may debate whether hosts have sufficient information to perform a valid choice, and it is a complex debate. Some very simple appliances probably never will have any information; large servers potentially have tons of information available; personal computers are somewhere in between. It is not unrealistic to expect progress in this area, either by communication between the hosts and the routers, by sharing of experience between hosts, or maybe by innovative application design that would for example implement a file transfer by parallel retrieval of fraction of the file from multiple sources. At worst, a host can always try the proposed addresses one by one, and pick the first one that actually works -- not very elegant, but definitely workable. 3.2 Source address selection The source address selection in most hosts immediately follows the destination address selection. When a host has multiple interfaces, the normal procedure is to select the destination address, then identify the interface over which packets bound to that address will be routed, and finally select a source address associated to that interface. When the host has multiple addresses attached to an interface, which is the case with host centric IPv6 multihoming, the host could in theory pick any of these addresses, or at least any of those that have an appropriate scope. In our example topology, supposing that X has selected the destination address "C:Y", it can choose as source address either "A:X" or "B:X". Huitema, et al. Expires August 10, 2004 [Page 7] Internet-Draft Host-Centric IPv6 Multihoming February 2004 Choosing the source address will affect the reverse path of the connection, as the source address of the message will become the destination address of the responses. This may be a serious matter in asymmetric applications like web access, in which the bulk of the data is sent by the server to the client. If the multiple addresses correspond to different ISP, the hosts should normally pick the source address that will provide the best performances. As for destination address selection, we may expect that the host will have some knowledge of the effect of choosing one or the other address, for example by observing that web pages are served faster through one address than through the other. 3.3 The site exit issue A special complication appears when the ISPs who serve the multihomed site perform "source address selection." In our generic configuration, we assume that X is served by ISP A and B, and thus can be reached by the addresses A:X and B:X. We also we assume that Y is served by ISP C and D, and thus can be reached by the addresses C:Y and D:Y. To communicate with Y, X will choose the destination address that appears to be easier to reach, for example D:Y; then, it will choose the source address that provides the most efficient reverse path, say A:X. Suppose now that the ISP connections at Site X are managed by two different site exit routers, RXA and RXB, and that there is a similar configuration at Site Y, with routers RYC and RYD. /-- ( A ) ---( ) --- ( C ) --\ (RXA) ( ) (RYC) X (site X) ( IPv6 ) (Site Y) Y (RXB) ( ) (RYD) \-- ( B ) ---( ) --- ( D ) --/ Within Site X, the interior routing will decide which of RXA or RXB is the preferred exit router for the destination "D:Y"; similarly, within Site Y, the interior routing will decide which of RYC or RYD is the preferred exit for destination A:X. If the chosen exit router at Site X is RXA, the packet will flow freely to RYD; If the chosen exit router at Site Y is RYD, the response will also flow freely. However, if the exit routers are RXB or RYC, and if the ISPs perform ingress filtering, we have a problem: ISP B sees a packet coming from RXB, whose source address does not match the prefix assigned by B to X; ISP C, similarly, sees a packet whose source address does not match the prefix assigned by that ISP to Y. If either of these ISPs decides to drop the packet, the communication will be broken. Huitema, et al. Expires August 10, 2004 [Page 8] Internet-Draft Host-Centric IPv6 Multihoming February 2004 3.4 Rapid reaction to topology changes Network conditions change over time. In order to meet the performance requirement, we must allow the use of the best path at any time; In order to meet the "redundancy" requirement, we have to make sure that if a network connection breaks, the corresponding prefix is not used as either a source or a destination address. We may assume that the destination address selection algorithm mentioned in 3.1 will naturally result in the selection by X of an appropriate address for Y; X may for example try in turn the addresses C:Y and D:Y, and retain the address for which a response comes back. However, we must make sure that X selects a source address that will be reachable: for example, if the link to ISP A fails, X must make sure that it uses as source address B:X, not A:X. Huitema, et al. Expires August 10, 2004 [Page 9] Internet-Draft Host-Centric IPv6 Multihoming February 2004 4. Analysis of solutions to the site exit issue The site exit issue is caused by ingress filtering at the site egress. In this section, we will analyse four ways to solve the issue: somehow relax the source address check, implement source address dependent routing, ask hosts to pick "the right" source address, or ask routers to somehow rewrite the packets so that it can pass the source address checks. We will then compare the proposed solutions, in order to prepare a recommendation. 4.1 Relaxing the source address checks An obvious way to avoid failures due to ingress filtering is to simply make sure that all the addresses used by the hosts of a given site will be considered acceptable by each of the site's providers. In our site X example, that would mean that provider A would accept addresses of the form "B:X" as valid, and that provider B will in turn accept addresses of the form "A:X" as valid. One way to achieve this is simply to ask the service provider to turn off source address checks on the site connection. This requires a substantial amount of trust between the provider and the site, as source address checks are in effect delegated to the site routers. One possible way to achieve this trust is to make sure that the site routers, or possibly the site firewalls, meet a quality level specified by the provider. Another way to achieve this relaxed level of checking is to check source addresses against a list of "authorized prefixes" for the site connection, rather than simply the single prefix delegated by the provider. This solution requires that the site communicates the authorized prefixes to the provider, either through a management interface or through a routing protocol. This is obviously more complex than simply lifting the controls, and in fact ends up with a very similar requirement of trust: the provider has to believe that the site will transmit the right prefixes. A special case occurs when the site exit is an "automatic tunnel" interface, such as 6to4 or Teredo. Source address control for automatic tunnels is delegated to the "other side" of the tunnel, in practice to a very large number of relay routers located across the Internet. Checks are based on the correlation between the IPv6 source address and the IPv4 source address used in the tunneling protocol. Asking each potential end of the tunnel to relax its checks is not realistic; in practice, this means that the exit routers will have to obtain the right to use as source address a privileged IPv4 address, such as the 6to4 anycast address; this will imply a negotiation with the provider of the IPv4 service. Huitema, et al. Expires August 10, 2004 [Page 10] Internet-Draft Host-Centric IPv6 Multihoming February 2004 In conclusion, relaxing the source address checks requires some form of explicit trust between the site and its providers. There is no doubt that this level of trust will exist in many cases; there is also no doubt that there will be many cases in which the provider is unwilling to grant this trust, particularly in the case of small sites, such as for example home networks dual-homes to a DSL provider and a cable network provider. 4.2 Source address dependent routing Another solution to the site exit problem is to perform some kind of source routing within the site, so that the site exit is effectively a function of the source address in the packet. Current routers generally do not implement any kind of source address dependent routing; this implies that this solution would have to be "rolled in" progressively in the site, following a generic schema such as: Multiple site exits | | | | -----+-----+-----+-----+----- ( ) ( Source based routing domain ) ( ) ----+----+----+----+----+---- ( ) ( Generic routing domain ) ( ) ----------------------------- In this schema, all site exit routers are connected to a source based routing domain. Packets initiated in the generic routing domain and bound to an "out of site" address are passed to the nearest access point to the source based routing domain, using classic "hot potato" routing. The routers in the source based routing domain maintain as many parallel routing tables as there are valid source prefixes, and would choose a route that is a function of both the source and the destination address; the packets exit the site through the "right" router. There are multiple possible implementations of this general concept. The simplest implementation is to have only one exit router for the site; this exit router chooses the exit link on the basis of the source address in the packet. This simple implementation might be adequate for very small sites, but introduces a single point of failure, and thus fails to meet the "redundancy" requirement of multihoming. Huitema, et al. Expires August 10, 2004 [Page 11] Internet-Draft Host-Centric IPv6 Multihoming February 2004 In the most complex set up, each router of the site would maintain as many parallel routing tables as there are valid source prefixes, and would choose a route that is a function of both the source and the destination address. This solution enables "shortest path" routing and can provide an arbitrary level of redundancy. However, maintaining parallel routing tables requires a massive re-engineering of routers and routing protocols, and thus would be hard to deploy in the short term. A slightly less complex implementation is to connect all exit routers to the same link, e.g. to what is often referred to as the "DMZ" for the site. This solution requires that all routers connected to the DMZ are upgraded to perform source address based routing. This configuration is less fragile than a single router solution; however, the single link requirement seems to preclude "geographic redundancy" between the site exits. It does requires the re-engineering of some routers, but not necessarily all routers of the site. In practice, it could be a way to "phase in" the most complex setup described in the previous paragraph. A much simpler alternative is to establish a mesh of "tunnels" between the site exit routers. A site exit router that receives a packet bound for an out-of-site address would perform a source address check before forwarding the packet on one of its outgoing interfaces; if the source address check is positive, the packet will effectively be sent on the interface; if it is not, the packet would be "tunneled" to a more adequate router. The main requirement of the tunneling alternative is that site-exit routers be able to perform address checks, and that each site exit router be able to associate to each valid site prefix the address of a corresponding site exit router. An obvious possibility is to configure prefixes and corresponding addresses in each router; it would however be preferable to derive these addresses automatically. A strong assumption of the IPv6 architecture is that all prefixes of a site will have the same length; it is thus possible to derive a prefix from the source address of a "misdirected" packet, by combining this prefix with a conventional suffix. The suffix should be chosen to not collide with the subnet numbers used in the site; a null value will be inadequate, since it could be matched by any router with knowledge of the prefix, not just the site exit router; a value of "all ones" could be adequate. In order to enable tunneling, each router managing a site prefix will then inject a "host route" for its locally managed prefixes in the interior routing protocol. Site exit routers performing automatic tunneling can then use the standard routing procedures to detect whether the anycast address corresponding to the prefix in use is Huitema, et al. Expires August 10, 2004 [Page 12] Internet-Draft Host-Centric IPv6 Multihoming February 2004 reachable; they can automatically reject, rather than tunnel, packets whose source address does not correspond to a reachable anycast address. An inconvenience of the set-up is that some packet will follow a less than direct path; we will see in the next section how that could be palliated by host based processing. Source based routing allows for a large diversity between the site exits; it also allows for host based policy decision, since a host can influence the routing of a packet by choosing the appropriate source address. There is however one drawback of any source address based scheme, the impossibility to use "asymmetric" path between two sites: ..................................> ./-- ( A ) ---( ) --- ( C ) --\... .....>(RXA) ( ) (RYC)....> X (site X) ( IPv6 ) (Site Y) Y <.....(RXB) ( ) (RYD)<.... . \-- ( B ) ---( ) --- ( D ) --/... <................................... Using source based routing implies that if the host X chooses the source address B:X, then its packets will exit through router RXB, never through RXA. This may provide lesser performances if a link is congested in one direction but not in the other. However, source based routing would allow four paths, A-C, A-D, B-C and B-D, thus providing an adequate redundancy and allowing a great deal of performance optimization. 4.3 Source address selection by the host The site exit issue would be mitigated if the hosts chose a source address that would be compatible with the exit point chosen by the routing protocol, or alternatively if the host tunneled the packet directly to an adequate exit router. The first alternative could be called "source address discovery". In many ways, source address discovery is similar to path MTU discovery. The two issues are similar: packets that do not meet some criteria fixed by the network are dropped; the host has to find the cause of the loss, and to take action in order to make sure that these packets will be accepted. In the path MTU case, the action is to use shorter packets; in the ingress filtering case, the action is to present a different source address. Huitema, et al. Expires August 10, 2004 [Page 13] Internet-Draft Host-Centric IPv6 Multihoming February 2004 To implement source address discovery, the hosts would have to introduce a "preferred source address" parameter in the "destination cache" mentioned in the Neighbor Discovery standard [3]. The primary purpose of the cache is to link a destination address to a next hop neighbor; it is also the repository of per-destination parameters such as the path MTU; it is the natural repository for the new parameter. The source prefix in the destination cache would be used during source address selection, to select an available interface address that matches the prefix. As for path MTU discovery, source address discovery requires that the hosts receive some information from the network. Such information can be conveyed in an ICMP Destination Unreachable error message with code 5 which means source address failed ingress policy [18]. The router is supposed to send such message when the packet is discarded because of ingress filtering issues. The error message contains information about the packet that triggered the error. However, the host will also need information about the source address prefix that should be used to pass the source address check. The proposed format of the error message does not includes such information. However, a proper choice of the source address by the router that generates the message can provide a good substitute. This means that the router that generates the error message will have to include the prefix that complies with the ingress filtering in the source address of the packet that carries the error message. The host will then select the source address to be used for the selected destination by performing a longest prefix match between the source address contained in the error message and the potential source addresses. In the absence of an explicit ICMP message, the hosts would have to rely on a trial an error process, noticing that packets get dropped and trying retransmissions with alternate source addresses; the experience of path MTU discovery shows that such processes are awkward and error prone. An alternative to source address discovery is "exit router discovery", i.e. the discovery by the source of the preferred exit router for a given source address. This requires a slightly different change to the caches used in neighbor discovery, specifically the management of a "source exit cache" that associates a specific source address with an exit router, or maybe the combination of a destination address and a source address with an exit router. As with source address discovery, this would be learned through an ICMP message; this message would not be an error message, but rather a variation of the redirect message. After receiving such messages, the host will tunnel to the specified exit point the packets sent from the source address to the destination; the exit point will decapsulate these packets and send them over the appropriate exit link. Huitema, et al. Expires August 10, 2004 [Page 14] Internet-Draft Host-Centric IPv6 Multihoming February 2004 The "exit router discovery" procedure appears to be superior to the "source address discovery." Both solutions require approximately the same amount of resource in the host, but the exit router discovery has two advantages: it enables hosts to actually specify the point of exit from the site, thus giving them a greater amount of "policy control". We should note that neither "source address discovery" nor "exit router discovery" are implemented in current hosts. In order to accomplish the goal expressed in [7] that hosts implementing the current version of IPv6 can continue to operate in a multi-homed site, even if they would not take advantage of multihoming; in consequence, these procedures can only be used as an optional optimization. 4.4 Packet rewriting at exit router In section 4.2, we explained how a site exit router that discovers that a packet bound out of the site has the "wrong" source address can route the packet to an alternative exit. Another way to pass the source the source address check is to modify the packet, which could in theory be done by replacing the source address or by encapsulating the packet using "IPv6 in IPv6". In fact, replacing the source address is not necessarily a good idea, since this will remove information from the packet; it also requires some level of cooperation between the exit router and the host, if only to understand what alternative source addresses can be used by the host, if any. One could preserve the information by encapsulating the packet in a new IPv6 header, using "IP in IP". The source address of the new header will be the address used by the router on the exit interface, the destination address will be the original destination, and the payload type will be set to "IPv6." After the insertion of the option, the outgoing packet will have the following values: * outer IPv6 header source address: address of the site egress interface, * outer IPv6 header destination address: from initial packet, * outer IPv6 header payload type: "IPv6", * inner IPv6 header source address: source address of initial packet, * inner IPv6 header destination address: from initial packet, Huitema, et al. Expires August 10, 2004 [Page 15] Internet-Draft Host-Centric IPv6 Multihoming February 2004 * inner IPv6 header payload type: payload type of initial packet, 4.5 Comparison of the site exit solutions The four solutions that we have reviewed have different advantages and inconveniences. The may differences are in terms of deployability, generality, redundancy, policy control, and impact on existing hosts, i.e. minimal implementations of IPv6 that would use only one of the available prefix for the site, that would not perform any more sophisticated logic than picking a destination address at random among multiple alternatives, and that would not understand any additional IPv6 option or any additional ICMP message. The relaxation of source address checks detailed in 4.1 is easy to deploy, and would not affect minimal hosts. It is a perfectly reasonable solution for large sites, i.e. the sites that benefit of IPv4 multihoming today: it should not be more complex to convince a provider to relax address checks for a particular customer tomorrow, than to convince today a similar provider to advertise in its routing table the global IPv4 address of the site. If we choose this solution, we should choose its simplest implementation, i.e. one in which the provider completely delegates source address checks to the site's router or firewalls. This is however not a general solution, since we cannot expect all sites to convince every provider to relax their checks. The rewriting at exit routers appears to be an inferior solution. It is not really easier to implement than the "tunneling" variation of source routing at the exit sites: if a router can detect that a source address does not pass the checks for a proposed interface, and if it can encapsulate the packet before forwarding it, then it could just as well tunnel the packet to the "correct" exit router for the site. Tunneling the packet to its final destination actually has a larger impact on the existing hosts than simply tunneling the packet to another router: we have to assume that the destination host is willing to accept tunneled packets, which is not an obvious proposition. Since the packet is tunneled, the destination host has to trust that the source address in the encapsulated packet is genuine; in the absence of an authentication header, this is risky proposition. When the source address checks cannot be relaxed, the best solution is probably to perform some kind of source address based routing to the adequate exit router. In the long term, the IETF may develop internal routing protocols that take into account the source address as part of the "reachability information" for a set of destinations; in the short term, there are no such protocols, and we have to rely on a tunneling mechanism between site exit routers. Huitema, et al. Expires August 10, 2004 [Page 16] Internet-Draft Host-Centric IPv6 Multihoming February 2004 Exit router discovery is a natural complement of the tunneling mechanism between site exit routers. When an exit router tunnels a misdirected packet towards another exit, it may send an appropriate "exit redirection" ICMP message. If the host is a minimal IPv6 host, the ICMP message will be ignored; further packets will continue using the same slightly sub-optimal path. On the other hand, if the host has been upgraded to take advantage of multi-homing, the packets will be tunneled to the appropriate exit router; they will follow a direct path to this router. Huitema, et al. Expires August 10, 2004 [Page 17] Internet-Draft Host-Centric IPv6 Multihoming February 2004 5. Analysis of solutions to provide rapid reaction to topology changes In order to fulfill the "redundancy" requirement, a multihoming solution has to provide the means to identify the available exit paths towards a given destination and carry packets through it. In other words, a mechanism to detect unavailable exit paths is required, so that they are not used. We will analyze the different mechanisms to perform the path selection in two situations: path selection when establishing a new communication and path selection during the lifetime of a communication. These two problems are quite different, since the timing requirements are different in the two situations and also requirements imposed in the addresses to be used are different. 5.1 Path selection when establishing a new communication 5.1.1 Externally initiated communications We will first analyze the mechanism used by hosts outside the multihomed site to select among the paths to the multi-homed site. We have already assumed that the multihomed site will have as many prefixes as ISPs, and that it will assign multiple addresses to every host that will benefit from multihoming. It is also assumed that those addresses will be announced through the DNS. So, when an external host tries to establish a communication, it will first obtain all the host's addresses from the DNS. Then it will try to use one of them and if it succeeds the communication is established; and if not, it will try with the next address. Considering that each address is routed through one and only one provider, the selection of an address implies the selection of a provider, then it implies the selection of a incoming path to the multihomed site. So, for external hosts, incoming path failure detection and incoming path selection is already being performed by the external host itself and the provided capabilities are enough to provide support to the multihomed environments. When the host within the multihomed site replies to the incoming packet, both the destination and the source addresses are already determined, so no selection has to be performed by the host in the multi-homed site. Moreover, since the incoming packet has reached the host within the multihomed site, and assuming that some mechanism to guarantee ingress filtering compatibility mechanism is being used, the exit path will be the same than the ingress path, so it is likely to be working properly. 5.1.2 Internally initiated communications We will next analyze the mechanisms required within the multihomed Huitema, et al. Expires August 10, 2004 [Page 18] Internet-Draft Host-Centric IPv6 Multihoming February 2004 site to select among the multiple path connecting the site to the Internet. When a host within the multihomed site sends a packet to a given external destination address, the exit path through which the packet will be routed has to be selected. In order to select a path two mechanisms are needed: a mechanism to discover the available paths and a mechanism to route the packets through the path identified as available. We have two elements that may perform these tasks: the routing system and the host itself. We will analyze the following possibilities: The first possibility is to let the intra-site routing system perform both tasks. The second possibility presented is to let the host do both tasks. The third possibility is to use the routing system to identify the available paths and to use a mechanism in the host to force the routing of packets through the identified path. The fourth possibility where the host identifies the available path and the routing system routes the packet through the path identified by the host doesn't seems a reasonable approach to us, so it will not be included in our analysis. 5.1.2.1 Exit path selection by the intra-site routing system One possibility is to let the intra-site routing system perform the complete exit path selection mechanism. In order to do that, intra-site routing system requires information about which destinations are reachable through each one of the exit paths. This means that each one of the providers has to inform the multi-homed site which destinations are reachable through him. Normally, the BGP protocol is used for this task. From the multihomed site perspective, there are two difficulties with this approach: first, the amount of information that is to be injected in the intra-site routing system is important and second, running the BGP protocol is more than a trivial task. While there are some medium-big multihomed sites that certainly can deal easily with these two issues, other smaller multi-homed sites may not deal with them so easily (imagine for instance a site consisting a few PCs on a single Ethernet and a single router connected to the Internet through a DSL access and a cable access). We can explore approaches to try to reduce the amount of routing information to be injected to the multi-homed site. The most aggressive approach would be to inject only a default route through each of the ISPs. This case works fine when one of the direct links Huitema, et al. Expires August 10, 2004 [Page 19] Internet-Draft Host-Centric IPv6 Multihoming February 2004 between the multihomed site and ISP fails, but, if we only want to provide protection for this specific case, RFC 3178 provides a solution that it is simpler overall since it deals with all the problems for this particular case (like ingress filtering, transport survivability, etc). So, since we are looking for a solution that provides better fault tolerance capabilities than RFC 3178, we need more information to be injected to the intra-site routing system. We need then alternatives that allow us to obtain better fault tolerance. A possible approach is to filter the accepted routes based on the AS path length, as proposed in [12]. By this mechanisms, the multihomed site would only accept routes with an AS path attribute whose length is no longer than x ASes. This approach allows reducing the amount of routing information while still achieving a high level of fault tolerance. The value of x is a trade-off between the two of them. As more routing information is injected into the site (higher x), better path selection will be performed and better fault tolerant capabilities will be provided by the solution, but at the same time more resources will be needed within the multihomed site. However, configuring filters raises the difficulty of running BGP, requiring additional BGP expertise in the end-site, making the adoption of this solution harder for small unmanaged sites. 5.1.2.2 Host based exit path selection An alternative to intra-site routing system exit path selection is to move exit path selection to the host itself. In order to enable the host to perform the exit path selection, two mechanisms are needed: a mechanism to discover available paths and a mechanism to enable the host to force the routing of packets through the selected exit path, overruling intra-site routing system routing. 5.1.2.2.1 Mechanisms to force the routing of packets. A possible mechanism to let the host force the path of the packets is to make a tunnel directly to the exit router. In order to do that, the host must be able to discover the address of the exit router. Using an "Exit Router Discovery" ICMP message as presented in section 4.3 would be an option. An alternative to tunnels could be the usage of routing headers. However this is considered an inferior solution since the routing header would be carried all along the path to the final destination even if it were not needed. Another mechanism to enable the host to select the exit path is available when some form of source address dependent routing is used within the multihomed site. As it has been presented in section 4.2, if each exit ISP is associated with one of the available prefixes, and source address dependent routing is used, selecting the prefix to Huitema, et al. Expires August 10, 2004 [Page 20] Internet-Draft Host-Centric IPv6 Multihoming February 2004 be included in the source address implies the selection of the exit ISP through which the packet will be carried. So, source address dependent routing can be considered as an option to allow the host to select the exit path. 5.1.2.2.2 Mechanism to discover available and unavailable paths A mechanism to identify available paths is just to let the host do trial and error procedure. That is, in order to reach a certain destination, the host tries every possible exit path. The procedure can be carried out either sequentially or in parallel, that is, the host can try with every path simultaneously or it can try with one path and if the chosen path fails then it tries with the next one. The benefits and drawbacks of these two approaches are clear: the sequential procedure may take longer to find the available path, but the parallel procedure consumes more resources since multiple packets are sent every time an available path has to be discovered. However, the implementation of a failure detection mechanism based on sending packets may be trickier than what it may seem. A possible approach could be to define a new protocol for detecting available paths that sends probe packets end to end. However, a solution that doesn't impose changes in hosts outside the multihomed site is preferred because it is easier to deploy. So, we have to use already available mechanisms. Among the available choices, we could use ICMP echo packets to detect path availability. The problem here is the wide adoption of ICMP filtering because security issues. The other available option is to use data packets as probes. The main problem here is that not all applications are bi-directional, so there may be cases when no packets will return but the path is available. However, we consider that an important number of applications are bi-directional, so we will explore this possibility (Note that we are not considering the multicast case here, where the unidirectional flows are more common). So, a path failure detection mechanism based on data packets stores the exit path information corresponding to a destination address in a cache, the Exit Path Cache. The information contained in this cache depends on the mechanism that is used to force the routing of the packet by the host. If the tunnel mechanism is used, the address of the exit router and the source address to be included are cached. If source address based routing is used, only the source address to be used is cached. So, when a packet is to be sent to a certain destination address, the Exit Path Cache is searched for an exit path corresponding to the destination address. If no exit path is found in the cache, the host has no knowledge about the available paths, so it has to start the failure detection procedure by sending packets through all the Huitema, et al. Expires August 10, 2004 [Page 21] Internet-Draft Host-Centric IPv6 Multihoming February 2004 available paths. As we have seen, such procedure can be performed sequentially or in parallel, but in any case packets will be sent through the available paths and the host will wait for replies. When the first reply is received (whether because packets through all available paths have been sent simultaneously or because packets through different exit paths have been sent and a timeout has occurred, so the packet has been retransmitted through an alternative destination), the exit path used is stored in the Exit Path Cache and following packets are sent through the same exit path. Exit Path Cache entries have a finite lifetime. An Exit Path Cache entry lifetime is extended every time that a packet is received coming from the corresponding exit path. When an Exit Path Cache entry lifetime expires, the failure detection procedure is performed when new packets arrive for such destination. A case that has to be considered is when no reply packets for a given destination are received from any exit path. Such behavior may have two causes: the application generates unidirectional traffic, so no packets are supposed to arrive or all the paths are down. In any of the two cases the mechanism can't do anything to select the exit path, so when such situation is detected, a random exit path has to be selected and used. So, an Exit Path Cache entry is generated with a random path and with a certain lifetime. When the lifetime expires, the failure detection mechanism is performed again, so that if the case was that all exit paths were down, the mechanism can detect when one of the paths is up again. Note that this would cause additional overhead for unidirectional applications, so the failure detection mechanism should not be performed very often i.e. the lifetime should not be very low. 5.1.2.3 Hybrid approach: Routing system based failure detection and host based exit path selection An alternative approach is to obtain the information about available paths from the routing system but let the host to force the routing of packets through the identified exit path. The benefit of this approach is that the routing information injection into the intra-site routing system is not required because the exit path is selected by the host. This hybrid approach requires a mechanism to convey the path availability information from the routing system to the hosts. Considering the amount of information involved, we consider that it is better to limit the path information stored in the hosts to the information concerning the paths that the host is currently using. There are two approaches that can be used at this point. One possible approach is to define a new protocol to let the host to Huitema, et al. Expires August 10, 2004 [Page 22] Internet-Draft Host-Centric IPv6 Multihoming February 2004 query a server for the correct exit path to be used to reach a certain destination, for example as defined in [16]. The server would have to be configured with enough information to answer those queries. For instance the server has to know all the BGP information that is received from each one of the ISPs, the associated prefix and the address of the corresponding exit router. So, when a host wants to initiate a communication with an unknown destination address, it queries the server and obtains the exit path to be used. Then the host itself forces the packet to be routed through the exit path. An alternative option is to let the exit routers to inform the host about the correct exit path to be used. In this case, only the exit routers are running BGP. So, when a host sends a packet to a new destination, it randomly selects the exit path. More likely, the host will randomly select a source address and won't tunnel the packet, so that the packet is carried to the default route. In case that the destination contained in the packet is not reachable through the ISP whose prefix has been included as source address, but the exit router knows because of BGP that it is reachable through an alternative exit router, the exit router will send an ICMP error message containing the exit path information back to the host. A particular case of this approach can be used when the failure has occurred in the direct link. In this case, the exit router can detect the outage and considering that no destination is reachable through this ISP, simply deprecate the prefix. This approach is only an optimization since it does not address the general case. 5.2 Preserving established communications Multiple solutions for preserving established communications have been proposed such as HIP, SIM, ODT, LIN6, MAST, NOID, CB64. Many of these approaches mainly focus on how to present an unchanged IP address to the upper layers through changes in the address used to actually reach the host. However, not only such mechanism is required in order to preserve established communications, but a mechanism to perform path selection is also required (both a mechanism to identify available paths and a mechanism to force the routing of packets through the identified path are required). Additionally, a mechanism to solve the site exit issue may be needed in those solutions. Next versions of this document will include an analysis of which mechanism can be used to select paths during the lifetime of a communication and how such mechanisms can interoperate with the proposed solutions. Huitema, et al. Expires August 10, 2004 [Page 23] Internet-Draft Host-Centric IPv6 Multihoming February 2004 6. Integrating Solutions In this section we will integrate solutions, combining a site exit issue solution with a path selection solution. Next, we will present what we consider to be the most natural combinations of a solution for the site exit issue and an exit path selection mechanism. Other combinations may be possible but they don't seem very natural so far. Perhaps future versions of this document will consider them if it seems appropriate. 6.1 Solution 1: Relaxing source address checks + Intra site routing system based exit path selection The site exit issue is addressed relaxing the source address checks at the ISP, since the required level of trust exists between the site and the ISPs. The exit path selection is addressed using BGP and injecting some of the information into the intra-site routing system. Since BGP expertise is available, appropriate filters can be configured. Requirements: - enough level of trust between the site and the ISPs in order to relax the source address check - enough expertise to run BGP and configure appropriate filters - enough resources to import part of the global routing table into intra-site routing system Suitable for: big/medium sites. The solution is not deemed suitable for small sites because of the required level of expertise and resources. 6.2 Solution 2: Source address Discovery + Intra site routing system based exit path selection The host generates packet with one if its source address and then the packet is routed according the information available at the intra-site routing. When the packet reaches the site border router, it verifies the source address. If the source address is compatible with the selected ISP, the packet is forwarded as it is, if not, the exit router discards the packet and sends an ICMP Destination Unreachable error message (code 5) back to host informing the appropriate source address for the selected destination. Requirements: Huitema, et al. Expires August 10, 2004 [Page 24] Internet-Draft Host-Centric IPv6 Multihoming February 2004 - enough expertise to run BGP and configure appropriate filters - enough resources to import part of the global routing table into intra-site routing system - Required modifications: all hosts within the multihomed site have to be modified to implement the processing of the ICMP error in order to work properly. Communications initiated by hosts within the multihomed not implementing such processing will fail when selecting the wrong source address. Those hosts will not obtain even the level of service they would obtain in a single homed site. Suitable for: big/medium sites The solution is not deemed suitable for small sites because of the required level of expertise and resources. 6.3 Solution 3: Packet Rewriting at site exit + Intra site routing system based exit path selection The host generates packet with one of its source address and then the packet is routed according the information available at the intra-site routing. When the packet reaches the site border router, it verifies the source address. If the source address is compatible with the selected ISP, the packet is forwarded as it is, if not, the exit router rewrites the source address of the packet with a new prefix compatible with the exit ISP. Requirements: - enough expertise to run BGP and configure appropriate filters - enough resources to import part of the global routing table into intra-site routing system - Required modifications: all hosts within the multihomed site have to be modified to implement a mechanism to recognize reply packets with modified destination address as valid replies to the initial packet. Communications initiated by hosts within the multihomed site not implementing such mechanism will fail when using a source address that is rewritten at site exit. Those hosts will not obtain even the level of service they would obtain in a single homed site. Additional modification in applications and/or external hosts may be required. Suitable for: big/medium sites The solution is not deemed suitable for small sites because of the required level of expertise and resources. Huitema, et al. Expires August 10, 2004 [Page 25] Internet-Draft Host-Centric IPv6 Multihoming February 2004 6.4 Solution 4: Host based exit path selection + source address based routing In this case, an exit path is determined by the source address selected included in the packet. So, the host can force the routing of a packet through an exit path just by selecting the source address. So, the host determines which paths are available by sending packets with different source addresses. If reply packets arrive, the path associated with the destination address included in the reply packet is available, so the address is introduced in the site exit path cache. Requirements: - Configuration of source address dependent routing. This can be configured site wide or just at the site exit routers. In the second case, a mesh of tunnels between of the site exit router has also to be configured - Required modifications: implementation of the path discovery mechanism in the hosts of the multihomed site in order to benefit from multihoming. Hosts not implementing such mechanism can configure a single source address and behave as they were in a single homed site. Source address dependent routing is supported by some router vendor. Suitable for: small sites While this solution may be adopted by medium and big sites, those sites may prefer other type of solutions based on BGP because policy issues. This solutions relies on hosts to implement policing, since the hosts themselves perform the path selection. Other solutions based on BGP enable policy configuration on router or in central servers. This last option is considered to be more scalable with respect to the number of hosts within the site, making it more attractive for medium and big sites. 6.5 Solution 5: Host based exit path selection + site exit discovery In this case, hosts within the multihomed site tries to discover the available exit path by generating packets with different source address. In the case that the exit ISP corresponds to the selected source address, the packet is forwarded through the ISP. If not, the packet is discarded and an ICMP error message containing the appropriate exit router is sent back to the host. The host then retries forcing the routing of the packet, tunneling it directly to the exit router. The host identifies available paths when it receives reply packets. The host then stores the information about the source address and optionally about the exit router to be used in the site exit path cache. Huitema, et al. Expires August 10, 2004 [Page 26] Internet-Draft Host-Centric IPv6 Multihoming February 2004 Requirements: - Required modifications: implementation of the ICMP error generation mechanism in the routers. Implementation of the path discovery mechanism and the processing of the ICMP error in the hosts. Communications initiated by hosts within the multihomed not implementing such mechanism will fail when using an incompatible source address. Those hosts will not obtain even the level of service they would obtain in a single homed site. Suitable for: small sites While this solution may be adopted by medium and big sites, those sites may prefer other type of solutions based on BGP because policy issues. This solutions relies on hosts to implement policing, since the hosts themselves perform the path selection. Other solutions based on BGP enable policy configuration on router or in central servers. This last option is considered to be more scalable with respect to the number of hosts within the site, making it more attractive for medium and big sites. 6.6 Solution 6: Hybrid approach + source address dependent routing In this case, a server or the exit router has the information about the correct site exit router and source address to be used for a given destination. So, the host within the multihomed site contacts the server and obtains the correct site exit router and the appropriate source address. Then the hosts sends packets with the appropriate source address so that it routed trough the correct exit router, Requirements: - enough expertise to run BGP and configure appropriate filters - enough resources to import part of the global routing table into intra-site routing system - Required Modifications: the exit router or a server has to inform the host about the correct source address. So both the router and hosts has to be modified to implement the mechanism Suitable for: medium and big sites The solution is not deemed suitable for small sites because of the required level of expertise. 6.7 Solution 7: Hybrid approach + source address selection by the host In this case, a server or the exit router has the information about the correct site exit router and source address to be used for a given destination. So, the host within the multihomed site contacts Huitema, et al. Expires August 10, 2004 [Page 27] Internet-Draft Host-Centric IPv6 Multihoming February 2004 the server and obtains the correct site exit router and the appropriate source address. Then the host sends packets with the appropriate source address tunneling it to the correct exit router, Requirements: - enough expertise to run BGP and configure appropriate filters - enough resources to import part of the global routing table into intra-site routing system - Required Modifications: the exit router or a server has to inform the host about the correct exit path. So both the router and hosts has to be modified to implement the mechanism Suitable for: medium and big sites The solution is not deemed suitable for small sites because of the required level of expertise and resources. 6.8 Remaining combinations The remaining combinations of site exit issue solutions with site exit path selections mechanism are considered no to naturally match together. For instance, it is considered that sites that obtain the level of trust required from its provider to relax the source address checks will prefer to run BGP to obtain the available path information rather than using a host based or hybrid approach. In source address dependent routing and in site exit discovery approaches to the site exit issue, it is the host itself who selects the exit path (using the source address or tunneling). This type of mechanism seems hardly compatible with intra-site routing system exit path selection, since it is no longer the intra-site routing system that selects the exit path but it is the host through the source address who performs that selection. Huitema, et al. Expires August 10, 2004 [Page 28] Internet-Draft Host-Centric IPv6 Multihoming February 2004 7. Proposed solution In order to implement the host centric multihoming solution, we must solve the issues presented in the previous section. In this section, we will present the recommended ways to solve the site exit issue and how to trigger rapid reactions to failures. We will next present different solutions for different scenarios. As we have concluded from our analysis presented above, different solutions have different requirements and are then suitable for different type of scenarios. We will consider three different scenarios: - multihoming for small sites - multihoming for medium sites - multihoming for big sites 7.1 Multihoming solutions for small sites It is not likely that small sites can obtain some form of source address check relaxation from their IPSs, so an alternative solution to deal with the site exit issue is to be used. It is also considered that in general, small sites don't have neither the expertise nor the resources required to run BGP, so an alternative mechanism to react to topology changes is required. We think that the host based approach is the mechanism that better suits the requirements of the small sites. We will next present a set of mechanism and tools to enable multihoming is small sites. The goal is to propose a roadmap to adopt multihoming that preserves existent functionalities and adds new functionalities progressively. This would allow legacy systems to keep on working exactly the same way they did before multihoming adoption and then add new features to enable multihoming benefits 7.1.1 Step 1: preserving functionality for legacy hosts when becoming multihomed. Suppose that a single homed site becomes multihomed. The problem here is that the site exit issue will affect communications of the newly multihomed site. So, the first step is to deploy a solution for the site exit issue as simple as possible that does not require updating the hosts of the site, and if possible does not requires updating other equipment. Using such solution, legacy hosts within the Huitema, et al. Expires August 10, 2004 [Page 29] Internet-Draft Host-Centric IPv6 Multihoming February 2004 multihomed site will work as if they were in a singlehomed site. That is, they will not obtain multihoming benefits, but at least they will not fail because of multihoming. This solution also allows then attaching legacy hosts to the site and they will work as if they were in a singlehomed site. In line with the analysis presented in the previous section, our recommendation is to enable multihoming by establishing tunnels between the site exit routers. In order to implement this solution, we must define a way to convey the site exit addresses to the various routers in the site; the simplest solution, which we propose here, uses an anycast address that is arithmetically derived from the sites' prefixes. 7.1.1.1 Site exit anycast address The site exit anycast address solution assumes that all of the sites prefixes have the same length L; it also assume that we can define a conventional "subnet" associated to the prefix. The proposed solution is to compose the anycast address by appending an "all 1" suffix to the site prefix: <----- L bits -----> <---- 128 - L bits -----> +-------------------+-------------------------+ | Valid site prefix | 1111...............1111 | +-------------------+-------------------------+ -- Site exit anycast address -- Each site exit router that can forward to the outside packets whose source address is derived from a specific site prefix will advertise reachability of the corresponding site exit anycast address through the routing mechanism. 7.1.1.2 Tunneling to the appropriate exit Site exit routers are expected to perform necessary source address checks before forwarding any packet on a site exit link. The site exit router must check the source address first, in order to avoid local packets being routed to a black hole. If the result of the check is positive, the packet will be forwarded. If the result is negative, the router will derive a "site exit anycast address" from the source address of the incoming packet. If the anycast address is unreachable, the incoming packet will have to be discarded. If the anycast address is reachable, the incoming packet will be tunneled towards that address. Huitema, et al. Expires August 10, 2004 [Page 30] Internet-Draft Host-Centric IPv6 Multihoming February 2004 It is accepted that tunneling mechanism introduces additional overhead, but it is recommended because its fast deployability. However, in the long run, a mechanism based on source address dependent routing will provide better performance. Such mechanism can be gradually deployed as presented in section 4.2 7.1.2 Step 2: Optimizations to enhance the multihoming support 7.1.2.1 Site exit router discovery A problem with the approach presented in the previous section is that packets may be routed through a suboptimal path, because they are initially routed towards a site exit router and if the source address doesn't match, this site exit will send the packet through a tunnel to an alternative exit router. This problem can be solved using a Site Exit Redirection ICMP message. This ICMP error would be generated by the site exit routers when they receive a packet whose source address doesn't match with the exit ISP. So, after forwarding the packet through a tunnel to the appropriate site exit, the router generates a Site Exit Redirection ICMP message to inform the originating host about the correct site exit router for this destination and source address combination. 7.1.2.1.1 Site Exit Redirection ICMP message Routers send site exit redirect packets to inform a host of a better exit path on the path to a destination. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source prefix length | Redirection life time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Site Exit Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Huitema, et al. Expires August 10, 2004 [Page 31] Internet-Draft Host-Centric IPv6 Multihoming February 2004 IP Fields: Source Address: An address assigned to the router from which this message is sent. Destination Address: The Source Address of the packet that triggered the redirect. Hop Limit: 255 Authentication Header: If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. ICMP Fields: Type: TBD, IANA Code: 0 Checksum: The ICMP checksum. See [14]. Prefix length: The length of the source address prefix, in bits, expressed as a 16 bit integer, transmitted in network order, i.e. most significant byte first. Redirection lifetime: The number of seconds during which the redirection should remain in effect, expressed as a 16 bit integer, in network byte order. Site Exit Address: An IP address of the preferred exit router to use for packets sent using as source address the IPv6 destination of this packet, or using any source address whose prefix matches the first "prefix length" bits of this packet's IPv6 destination. Possible options: Redirected Header: As much as possible of the IP packet that triggered the sending of the Redirect without making the redirect packet exceed 1280 octets. 7.1.2.1.2 Host behavior Hosts can be programmed to perform "exit router discovery", i.e. associate to a source and destination address pair the address of the preferred exit router, and then tunnel packets directly to that exit router. Hosts will learn the address of the exit router through ICMP "Site Exit Redirection" messages. Huitema, et al. Expires August 10, 2004 [Page 32] Internet-Draft Host-Centric IPv6 Multihoming February 2004 Any redirection message poses a potential threat, since it can be used by third parties to misdirect and possibly capture traffic. In a secure set-up, hosts will establish a security association with the exit routers, and will only accept Site Exit Redirection messages that are properly secured by an authentication header. In the absence of a security association, the host may perform a number of checks before accepting a Site Exit Redirection ICMP message: * check that the IPv6 source address corresponds to a local prefix; * check that the prefix length has a realistic value, e.g. at least 48 bits; * check that the Site Exit Address matches the site prefix being redirected; * select a redirection life time that is the minimum of the ICMP value and a locally selected maximum duration. Since site exit discovery is a routing optimization, hosts should balance the routing gain with the possible security risk. 7.1.2.2 Rapid reaction to failures 7.1.2.2.1 Direct link failures In order to react to local failures, we must establish a communication channel that quickly signals these failures to the hosts. The logical channel to use is the "router advertisement" message, which the routers use to communicate to hosts the list of available prefixes. We propose here to use the "preferred" and "valid" flags in these prefixes to signal to hosts the addresses that should, or should not, be used as source address at any given time. This solution is sufficient when the site is composed of a single link; for more complex site, we propose to use the "router renumbering" mechanism to maintain an up-to-date list of available prefixes. 7.1.2.2.1.1 Use of Router advertisements The router advertisement messages are defined in [3]; their use for address configuration is defined in [4]. As specified in [3], the router advertisements include a variable number of Prefix Information parameters. Each Prefix Information parameter specifies: * an address prefix value, Huitema, et al. Expires August 10, 2004 [Page 33] Internet-Draft Host-Centric IPv6 Multihoming February 2004 * an "on-link" flag, used in neighbor discovery, * an "autonomous" flag, used for autonomous address configuration, * the "valid" lifetime, * the "preferred" lifetime. We propose to use the "preferred" lifetime to indicate whether addresses derived from the prefix can be used as source address in multihomed networks. When a prefix is temporarily not available routers MUST advertise a null preferred lifetime for that prefix. In conformance with section 5.5.4 of [3], the hosts will notice that the formerly preferred address becomes deprecated when its preferred lifetime expires. They will not use the deprecated addresses in new communications if an alternate (non-deprecated) address is available and has sufficient scope. Manipulating the preferred lifetime only solves part of our problem, since according to [3] the hosts should continue to use the "valid" source address in existing communications. To actually maintain the transport sessions that used the now unavailable link, we will need additional host improvements. 7.1.2.2.1.2 Use of Router Renumbering In order to advertise a null preferred lifetime for a specific prefix, the sites routers must be able to learn about that prefix. A possibility is to use the "Router renumbering" protocol [6][RFC2894] to pass this information. The protocol allows an authorized agent, in that case the egress site, to update the list of prefixes advertised by the site's routers. The protocol can be used to change parameters associated to a prefix, such as the preferred lifetime. 7.1.2.2.2 Reaction to other failures modes Based on the analysis presented in section 5 and 6, we recommend the adoption of a host based exit path selection mechanism to enable the hosts within the multihoming site to react to topology changes. Considering that we are recommending a solution for the site exit issue based on source address dependent routing, we can assume that the exit ISP is determined by the source address included in the packet. So, in order to force the routing of a packet through a particular ISP, the host only has to set the appropriate source address. As described in section 5, the proposed mechanism to identify available paths will be based on the trial and error Huitema, et al. Expires August 10, 2004 [Page 34] Internet-Draft Host-Centric IPv6 Multihoming February 2004 procedure. The following mechanism is to be implemented in host in order to react to topology changes. 7.1.2.2.2.1 Exit Path Cache An Exit Path Cache is created in the hosts. Each entry contain for a Destination Address, information about the corresponding Source Address and a lifetime. Exit Path Cache entry creation process: When the host receives a packet containing a Source Address SA and a Destination Address DA, the Exit Path Cache is searched for an entry that contains SA Destination Address field. - If such entry is found, the Source Address is verified. -- If the Source Address contains DA, then the lifetime of the entry is extended. -- If the Source Address is other than DA, then the cache entry is updated and DA is stored in the Source Address field. The lifetime of the entry is extended. (would this break some apps?) - If the entry is not found, the entry is created, with SA as the Destination Address and DA as the Source Address. The entry is blocked from changes for a certain period to avoid that multiple answers used in the next section produce suboptimal behavior. (the other option would be not to modify existent (valid) cache entries when packets with a different DA are received) 7.1.2.2.2.2 Initiating new communications When a host attempts to initiate a communication with a certain destination address D, it first verifies if an Exit Path Cache entry exists for that destination address D. If it does exists, the host obtains the source address to be used form it. If no entry exists for that destination address D, the host generates multiple packets, one per available source address, sends them and sets a timer. If a reply packet is received, the cache entry is created as described in the previous section. Following packets addressed to that destination will use the discovered source address if the applications does not sets the source address to be used. Huitema, et al. Expires August 10, 2004 [Page 35] Internet-Draft Host-Centric IPv6 Multihoming February 2004 If the timer expires before any packets containing D as source address are received, this may mean that there is no exit path available to reach destination D or that the application generates an unidirectional flow, so no packets are to be received. In any case, the issue cannot be addressed at this level, so the recommended behavior is that the host simply selects one source address S and use it for the packets addressed to destination D. In order to avoid the procedure to restart, a Exit Path Cache entry has to be created for this destination address, containing the selected source address. 7.1.2.2.2.3 Preserving established communications TBD 7.2 Multihoming solution for medium sites Medium sites are likely to be capable of running BGP but they may not be able to obtain enough trust from their ISP to relax the source address checks. So, medium sites could use the mechanisms proposed for small sites, but they are likely to benefit by integrating BGP in the multihoming solution. So, the recommended integration of BGP capabilities in the proposed small site solution basically affects the mechanism used to react to topology changes affecting non-direct links. This means that the solution for the site exit issue recommended for medium sites is also a mesh of tunnels as presented in section 7.2.1 allowing a smooth transition to multihoming without interfering with the installed base within the multihomed site. Also, we recommend the usage of Neighbor Advertisement and Neighbor Renumbering to convey information about direct link outages by deprecating the correspondent prefix, as presented in section 7.2.2.1.1. 7.2.1 Reaction to topology changes The proposed solution requires that the site exit routers run BGP with their correspondent providers. By doing so, exit router have information about reachable destinations through their directly connected ISP. Moreover, through IBGP sessions with the other site exit routers, they have information about reachable destination through the other ISPs. An Exit Path Cache is created in the hosts. Each entry contains for each Destination Address, information about the corresponding Source Address and a lifetime. Exit path Cache entries are created when the host receives a packet Huitema, et al. Expires August 10, 2004 [Page 36] Internet-Draft Host-Centric IPv6 Multihoming February 2004 as described in section 7.2.2.1.2.1 So when a host attempts to initiate a communication with a certain destination address D, it first verifies if an Exit Path Cache entry exists for that destination address D. If it does exist, the host obtains the source address to be used from it. If no entry exists for that destination address D, the host just selects one of the possible source addresses and includes it in the packet. When the packet reaches the site exit router the following situations are possible: 1. The destination is reachable through this site exit router and its directly connected ISP and the source address contains the prefix corresponding to the connected ISP. In this case, the site router forwards the packet through its directly connected ISP. 2. The source address contained in the packet corresponds to another exit router and the destination is reachable through the other site exit router (the one that corresponds to the source address). In this case, the router tunnels the packet to the correct site exit router and sends a Site Exit Redirection ICMP message (as defined in 7.2.2.1.1) back to the host, so that the host can send following packets directly to the correct exit router. 3. The destination is not reachable through the ISP that corresponds to the source address included in the packet, but it is reachable through another ISP. In this case, this packet has to be discarded and the host has to be informed that an alternative source address has to be used. The router then sends an ICMP Destination Unreachable Error message with code 5 (meaning source address failed ingress policy) back to the host, carrying in the source address the prefix that has to be used to reach the selected destination. A new Exit Path Cache entry is created containing the source and destination address. 4. The destination is unreachable through any of the ISPs, so the packet is discarded and an ICMP Destination Unreachable error message is sent back to the host. 7.3 Multihoming solution for big sites A big site is likely to have enough expertise and resources available to run BGP. Also, it seems likely that a big site can obtain the required level of trust from its providers to relax the source address checks. So, big sites are likely to adopt a multihoming Huitema, et al. Expires August 10, 2004 [Page 37] Internet-Draft Host-Centric IPv6 Multihoming February 2004 solution based on these two mechanisms, the relaxation of source address checks and the usage of BGP and the intra-site routing system to select the exit path. Source address check relaxation allows a big site to become multi-homing without prejudice to legacy hosts within the multi-homed site. Those hosts can still work properly as if they were in a single homed site. BGP provides information about what path reaches the selected destination. However, in case that one of the ISPs is down, the corresponding address is unreachable, meaning that such address is not to be used as a source address by hosts within the multihomed site that establish new communications, because there is no route available for return packets. In this case, a similar (but simplified) mechanism to the one proposed in the previous section about reaction to topology changes for medium sites is to be used. This mechanism is simpler because no ingress filtering considerations are involved, so the situation described in point 2 in the section above is no longer relevant. Huitema, et al. Expires August 10, 2004 [Page 38] Internet-Draft Host-Centric IPv6 Multihoming February 2004 8. Evaluation of Host centric solution and Multihoming Goals The MULTI6 working group has elaborated a list of goals for a multi-homing solution that is detailed in [7]. In this section, we will review how the host centric approach to IPv6 multihoming meets these goals, which are distributed in two subsections: matching the capabilities of IPv4 multihoming, and meeting additional goals. 8.1 Capabilities of IPv4 Multihoming 8.1.1 Redundancy The solution presented here can provide protection against: o Physical link failure, o Logical link failure, o Routing protocol failure, o Transit provider failure, and o Exchange failure. Basic redundancy is provided by the availability of multiple addresses, that can be tried in turn, and by a reliance on classic destination based routing protocols. We assume that if an address is reachable, the routing protocol will find a path that leads to it; at worst, the host will have to perform several transmission trials, using different addresses, until the destination is reached. On the reverse path, redundancy is based on the selection of an appropriate source address. The "preferred lifetime" mechanism allows even the simplest hosts to learn which addresses are robust enough to be used. Destination and source selection provide a protection against a failure of the site access link, which is catalogued in the goals as Physical link failure, or Logical link failure. The availability of multiple destination addresses provides a protection against Routing protocol failure, Transit provider failure, and Exchange failure on the forward path: the communication will succeed if at least one of the destination addresses can be routed. The protection against such failures on the reverse path is provided if multiple source addresses are tried. Huitema, et al. Expires August 10, 2004 [Page 39] Internet-Draft Host-Centric IPv6 Multihoming February 2004 8.1.2 Load Sharing An enterprise can distribute the inbound traffic by manipulating the "preference" associated to various addresses in the DNS, e.g. by using mechanisms such as MX records or SRV records. 8.1.3 Performance Performance enhancements can be obtained by appropriate development of destination address selection and source address selection algorithms. 8.1.4 Policy Classes of applications may be shifted to a specific provider by appropriate use of DNS records associated to specific services. For example, the NNTP traffic could be directed to the specific server "nntp.example.com", and the enterprise could decide to only advertise for that server an address provided by one of its providers. The Policy table defined in [15] allows to prefer a certain source address rather than others. Considering that the source address determines the exit path, the policy table allows to express the preferred exit path. 8.1.5 Simplicity Host centric multihoming is simple to deploy, since it does not require any cooperation between the site and its providers, or in fact between the various providers. The main requirement is to advertise an up-to-date list of prefixes in the router advertisements; this can be automated using the router renumbering protocol. 8.1.6 Transport-Layer Survivability TBD 8.2 Additional Goals 8.2.1 Scalability The host centric multihoming system does not impose any unreasonable requirements on the routing system: the sites use multiple addresses, but each of these addresses can be aggregated under the prefixes of their respective providers. Huitema, et al. Expires August 10, 2004 [Page 40] Internet-Draft Host-Centric IPv6 Multihoming February 2004 8.2.2 Impact on Routers In order to quickly signal to hosts any change in the sites' connectivity, the site routers should implement the "router renumbering" procedures, and the exit routers should be able to use that procedure if a physical or logical link becomes unavailable. Additionally, routers have to implement the new Site Exit redirection ICMP message and the proposed processing of the ICMP destination unreachable error message with code 5 (source address failed ingress policy). 8.2.3 Impact on Hosts The solution does not destroy IPv6 connectivity for a legacy host implementing [1], [2], [5] and other basic IPv6 specifications current in January 2004. Such hosts may not be taking the full benefit from multihoming; in particular, their transport connections may not survive the failure of a site connection. However, the preferred lifetime mechanism guarantees that after a re- homing event, the new connections of these basic hosts will follow an available path. Hosts will take better advantage of multi-homing if they implement better destination address and source address selection algorithms, exit router discovery. Each of these is a logically separate function that can be added to existing functions. The solution does not require changes to the socket API and/or the transport layer; such changes may however be required if the host wants to implement a combined selection of the source and destination addresses, which is an optional additional function. The solution allows host or application change to enhance session survivability. 8.2.4 Interaction between Hosts and the Routing System The interaction between a site's hosts and its routing system is limited to the normal processing of router advertisements. Upgraded host will be able to obtain additional information from the routing system through the newly defined ICMP messages. 8.2.5 Operations and Management It is possible to monitor and configure the multihoming system. Huitema, et al. Expires August 10, 2004 [Page 41] Internet-Draft Host-Centric IPv6 Multihoming February 2004 9. Things MULTI6 Developers should think about This section contains the answers to the questions contained in [17]. 9.1 The Answers 9.1.1 Routing 9.1.1.1 How will your solution solve the multihoming problem? The Host-Centric Multihomig proposal addresses multiple of the multihoming issues. In particular, Host Centric multihoming proposal includes mechanisms to: - Solve the site exit issue - Select proper (reachable) addresses when establishing a communication - Perform policing The Host Centric multihoming proposal does not includes a proposal to preserve established communications through outages. However, The compatibility of Host Centric multihoming mechanisms with proposed solution to provide transport layer connection survivability will be analysed in future versions of the document. 9.1.1.2 Uniqueness 9.1.1.2.1 Does your solution address mobility? No. 9.1.2 Identifiers and locators 9.1.2.1 Does your solution provide for a split between identifiers and locators? No. 9.1.3 On The Wire 9.1.3.1 At what layer is your solution applied, and how? All the proposed mechanisms work at the IP layer. Is it applied in every packet? Huitema, et al. Expires August 10, 2004 [Page 42] Internet-Draft Host-Centric IPv6 Multihoming February 2004 No. If so, what fields are used? Some packets may require to be tunneled to the correct exit router, so an additional IPv6 header may be required. 9.1.3.2 Why is the layer you chose the correct one? Host Centric Multihoming basically uses tools that are already available in some form in current implementations. While some modifications are required, the goal is to reuse as much of the existent mechanisms as possible. So, the layer used is the layer where these mechanisms already reside. 9.1.3.3 Does your solution expand the size of an IP packet? The solution does not expand the size of the packet but is uses tunnels in some occasions, so we will analyze the impact of tunnels in fragmentation in this section. Some packets require to be tunneled to the correct tunnel. Two type of tunneling is used: - Tunnels between the site exit routers: when packets reach the exit router selected by the intra-site routing system, the exit router verifies whether the source address is compatible with ingress filtering defined by the directly connected provider. If not, the packet will be tunneled to the appropriate exit router. Such tunnelling imposes a reduced MTU. There are two was this can be handled. One option could be to announce a reduced MTU within the site, so that hosts just assume a 20 bytes smaller MTUs always and tunnel overhead doesn't impose additional fragmentation. The other option would be just to let the tunnel endpoint to fragment when needed. - Tunnels between the host and the site exit router: when the host learns the appropriate exit router through the ICMP Site exit redirection message, the host will tunnel packet directly to the exit router. Again, in this case the host may need to fragment the packets because of the tunnel overhead. It should be noted that packets will only be tunnelled once, whether between exit router or from the host to the exit router. In no case a packet will be tunneled twice because of the multihoming solution. Now, if the option to announce a 20 byte smaller MTU within the site is adopted, it would be desirable that also the tunnels between the host and the exit router can use this reserved space. So an option could be to present the smaller MTU to the upper layers, but allow the tunnel interface to Huitema, et al. Expires August 10, 2004 [Page 43] Internet-Draft Host-Centric IPv6 Multihoming February 2004 send 20 bytes larger packets. Summarizing, the solution will imply a 20 byte MTU reduction within the multihomed site. This overhead can be eliminated by adopting a source address dependent routing within the site. 9.1.3.4 Will your solution add additional latency? Small sites: two strategies for detecting available path when initiating communications are presented: sequential retrial of paths or path retrial in parallel. The first approach would impose and additional latency in the case that the first path is not available. The second option would introduce packet overhead but would not increase the latency. Medium and Big sites: in this case, site exit router will have the information about destination address reachability. In the case that the destination address is not reachable through the ISP corresponding to the selected source address, the packet will be discarded and an increased latency will be generated. However, the introduced latency will reduced since the packet is discarded within the site. 9.1.3.5 Do you change the way fragmenting is handled? No, see above. 9.1.3.6 Are there any changes to ICMP error semantics? A new Site Exit redirection ICMP message is defined. see section 7.2.2.1 The processing of the ICMP destination unreachable error message with code 5 (source address failed ingress policy) will be modified according to the procedure described in section 4.3 9.1.4 Names, Hosts, Endpoints, or none of the above? 9.1.4.1 Please explain the relationship of your solution to DNS Host Centric Multihoming does not introduce a new namespace nor separates locators from identifiers. No changes to the DNS are introduced. Huitema, et al. Expires August 10, 2004 [Page 44] Internet-Draft Host-Centric IPv6 Multihoming February 2004 9.1.4.2 If you are not using DNS... No other mechanism is used. 9.1.4.3 Please explain interactions with 2-faced DNS No changes are introduced to the DNS. 9.1.4.4 Does your solution require centralized registration? No. 9.1.4.5 Have you checked for DNS circular dependencies? No changes are introduced to the DNS. 9.1.4.6 How does a host know its identity? No new identity is defined. The host learns its IP address by existent mechanisms. 9.1.4.7 What if a DNS server itself is multihomed? Host Centric Multihomed can be used to provide multihoming benefits DNS. In order to benefit from multihoming, the DNS server has to implement the host mechanisms, just as any other host within the multihomed site that benefits from Host Centric Multihoming. 9.1.4.8 What additional load will be placed on DNS servers? None. 9.1.4.9 Any upstream provider support required? for small sites: none For medium sites: running BGP with the site For big sites: relaxing ingress filtering, running BGP with the site 9.1.4.10 What application/API changes are needed? None. It is assumed that current applications are RFC 3484 compliant 9.1.4.11 Is this solution backward compatible with old IP version 6? Yes. Huitema, et al. Expires August 10, 2004 [Page 45] Internet-Draft Host-Centric IPv6 Multihoming February 2004 Can it be deployed incrementally? Please describe how. Incremental deployment is the major goal of the Host Centric Multihoming proposal. In order to enable incremental deployment, the following roadmap is proposed: 1- The first step is to preserve at least single homing functionalities when a single homed host that becomes multihomed. When a single site becomes multihomed, the site exit issue affects the communications of the hosts of the newly multihomed site. Establishing a mesh of tunnels between the site exit router in the case of the small and medium sites and relaxing the source address checks in the big sites overcomes this problems without imposing a general equipment upgrade. Moreover, the proposed solution only requires configuration of the specific devices. After this step, all the hosts within the multihomed site will work at least as if they were in a single homed site. 2- The second step is to enable some of the multihoming benefits with minor modifications. This would provide some degree of fault tolerance when the direct link between the site and its direct providers fails. 3- The third step is to enable most of the fault tolerance capabilities by upgrading the hosts to select the proper path. This step requires the upgrade of the hosts within the multihomed site. Does your solution impose requirements on non-multihomed/non-mobile hosts? No. The changes required by the solution are limited to the multihomed site. What happens if someone plugs in a normal IPv6 node? The normal IPv6 would work normally in the multihomed site as if it were in a single homed site and it will also obtain some multihomed benefits. 9.1.4.12 Is your solution backward compatible with IPv4? No. The proposed solution only works with IPv6. 9.1.4.13 Can IPv4 devices take advantage of this solution? No. Huitema, et al. Expires August 10, 2004 [Page 46] Internet-Draft Host-Centric IPv6 Multihoming February 2004 9.1.4.14 What is the impact of your solution on different types of sites? How are single homed sites impacted? No impact. How are small multihomed sites impacted? The proposed solution for small sites is customized for their special needs. It doesn't requires complex management (like BGP) nor lot of resources. It is basically host based and does not requires much configuration. How does it scale for large multihomed sites? For large sites a different solution is presented that requires additional expertise and resources but enables a higher degree of centralized control. What about ad-hoc sites such as an IETF event? If the hosts are upgraded to support the mechanism used in the multihomed site, they would obtain the multihomed benefits. If non-upgraded hosts are connected, they will obtain a service slightly better than the one offered in a single homed site. 9.1.4.15 How will your solution interact with other middleboxes? Just as regular IPv6 does. 9.1.4.16 Are there any implications for scoped addressing? No changes are introduce to the address architecture, so it is expected that the proposed architecture will interact with scoped addressing just as regular IPv6. 9.1.4.17 Are there any layer 2 implications to your proposal? No changes to the interaction with layer two are required. However, depending on how easily outages are detected, the performance of the solution may vary. For instance if direct link outages are rapidly detected, the correspondent prefix will be sooner deprecated and the performance of the solution will increase. 9.1.4.18 Referrals Referrals can be handled just as in regular IPv6. However, if Huitema, et al. Expires August 10, 2004 [Page 47] Internet-Draft Host-Centric IPv6 Multihoming February 2004 multihoming benefits are expected, the referral should include all of the IP addresses assigned to the host within the multihomed site, so that the receiver of the referral can try with the different addresses in case of failure. 9.1.4.19 What new information should applications be aware of? None 9.1.4.20 Legal Stuff None Huitema, et al. Expires August 10, 2004 [Page 48] Internet-Draft Host-Centric IPv6 Multihoming February 2004 10. Security Considerations The use of a site exit redirection ICMP message could potentially be used to redirect and intercept traffic; secure hosts should only accept such messages if they are properly authenticated. Huitema, et al. Expires August 10, 2004 [Page 49] Internet-Draft Host-Centric IPv6 Multihoming February 2004 11. IANA Considerations This document requests allocation by IANA of 2 new ICMPv6 message types. Huitema, et al. Expires August 10, 2004 [Page 50] Internet-Draft Host-Centric IPv6 Multihoming February 2004 12. Acknowledgements This memo incorporates text from a previous draft submitted by Richard Draves. We acknowledge Alberto Garcia Martinez, Cedric de Launois, Brian Carpenter, Dave Crocker and Xiaowei Yang for their reviews and comments. Huitema, et al. Expires August 10, 2004 [Page 51] Internet-Draft Host-Centric IPv6 Multihoming February 2004 References [1] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [3] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [4] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [5] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 2553, March 1999. [6] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000. [7] Abley, J., Black, B. and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003. [8] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000. [9] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2267, January 1998. [10] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, December 1995. [11] Johnson, D., "Mobility support in IPv6", Internet Draft , June 2003. [12] van Beijnum, I., "BGP", OReilly , 2002. [13] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [14] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. [15] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. Huitema, et al. Expires August 10, 2004 [Page 52] Internet-Draft Host-Centric IPv6 Multihoming February 2004 [16] de Launois, C. and O. Bonaventure, "NAROS : Host-Centric IPv6 Multihoming with Traffic Engineering", ID draft-de-launois-multi6-naros-00.txt, May 2003. [17] Lear, E., "Things MULTI6 Developers should think about", ID draft-lear-multi6-things-to-think-about-01, December 2003. [18] Gupta, M., "Message about new ICMP code points", IPv6 list message http://www1.ietf.org/mail-archive/working-groups/ipv6/ current/msg01431.html, February 2004. Authors' Addresses Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA Phone: EMail: huitema@microsoft.com URI: Richard Draves Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA Phone: EMail: richdr@microsoft.com URI: Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 EMail: marcelo@it.uc3m.es URI: http://www.it.uc3m.es Huitema, et al. Expires August 10, 2004 [Page 53] Internet-Draft Host-Centric IPv6 Multihoming February 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Huitema, et al. Expires August 10, 2004 [Page 54] Internet-Draft Host-Centric IPv6 Multihoming February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Huitema, et al. Expires August 10, 2004 [Page 55]