INTERNET DRAFT C. Huitema, R. Draves Microsoft Expires January 12, 2002 July 12, 2001 Host-Centric IPv6 Multihoming Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. 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. 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 corresponding addresses for each host. 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. We analyze in detail 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 requirements of IPv6 site multihoming. 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 corresponding addresses for each host; 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 Huitema, Draves [Page 1] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 provider; however, it opens a number of issues. We analyze in detail the problem created by the interaction between ingress filtering and multihoming. We then propose a set of specific solutions that enable host centric multihoming, specifically: the use of the preferred lifetime to inform hosts of the available site prefixes; the use of tunneling to redirect packet to the appropriate site exit router when ingress filtering is enforced; the definition of a site exit anycast address to automate this tunneling; and the definition of an ICMP message to inform hosts that the redirection took place. These solutions enable "un-modified" hosts to operate well in a multi-homed site; they can also be the basis for host improvements that let hosts take full advantage of multi-homing. We then review how these solutions meet the requirements of IPv6 site multihoming. 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 [RFC2119]. 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 two global IPv6 addresses, which we will call "A:X" and "B:X", formed by combining the prefixes allocated by ISP A and B to "site X" with the interface identifier of X. Similarly, Y has two addresses "C:Y" and "D:Y". We assume that X, when it begins communicating 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 with X. 2.3 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 Huitema, Draves [Page 2] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 link between a customer and an ISP. This process, which is described in [RFC2267] is intended to thwart a class of denial of service attacks in which attackers hide their identity by using a "spoofed" source address. 2.4 Site exit router A site exit router is an IPv6 router managing at least one of the connections between a site and the Internet. Ingress filtering is often implemented with an RPF (reverse-path forwarding) check. When receiving a packet from a customer site, the ISP router looks up the route to the packet's source address. If the arrival interface is not the route to the source address, then the packet is rejected. 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. 3 Host-Centric IPv6 Multihoming issues Host-Centric IPv6 Multihoming forces hosts to choose the source and the destination address of their IPv6 packets, in a way that makes the best usage, or at least a reasonable usage, of network resources. Most commonly, applications sequentially try destination addresses from the getaddrinfo API and the network stack performs source address selection [DASIP6] for each destination address. 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 ordering in getaddrinfo 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 applications perform this choice when the connection is instantiated; SCTP may perform similar choices through the life-time of the connection; UDP applications may perform this choice either for each packet, or at the beginning of an association. We may debate whether hosts have sufficient Huitema, Draves [Page 3] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 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 a fraction of the file from multiple sources. The destination address selection let hosts select an address from the list provided by names services such as the DNS. Improving the address selection algorithm may result in address choices that provide improved performances; however, if the selected address is in fact unreachable, the host will typically have to wait for a timer, notice the absence of response, and try another address in the list. One may debate whether this is better or worse than the current IPv4 solution, in which a domain may be temporarily unreachable while the routing converges to a new state; in any case, a solution that would not involve errors, delays and re-trials would be preferable. An obvious improvement here would be to make sure that the name servers to only list addresses that are reachable, and are quickly updated when a change in the site connectivity results in a change in the list of available addresses. 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 address, then identify the interface over which packets bound to that address will be routed, and finally select a source address assigned to that interface. When the host has multiple addresses assigned to an interface, which is the case with host centric IPv6 multihoming, the host could in theory pick any of those addresses, subject to the rules of [DASIP6] concerning address scope, preferred/deprecated configuration status, etc. 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". 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 ISPs, ideally the host would pick the source address that will provide the best performance. 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. Huitema, Draves [Page 4] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 3.3 The site exit issue A special complication appears when the ISPs who serve the multihomed site perform "ingress filtering." 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. To communicate with Y, X will try first the destination address that appears to be easier to reach, for example D:Y, using the longest-matching-prefix heuristic to compare the two destination addresses to its own source addresses; then, it will choose the source address that appears to provide the most efficient reverse path, say A:X, again applying the longest-matching-prefix heuristic [DASIP6]. 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 RYB. /-- ( 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 "C: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 RXB, the packet will flow freely to RYC; if the chosen exit router at Site X is RYC, the response will also flow freely. However, if the exit routers are RXA or RYD, and if the ISPs perform ingress filtering, we have a problem: ISP A sees a packet coming from RXA, whose source address does not match the prefix assigned by A to X; ISP D, similarly, sees a packet whose match the prefix assigned by that ISP to Y. If either of these ISPs decides to drop the packet, the communication will be broken. 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 Huitema, Draves [Page 5] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 fails, X must make sure that it uses as source address B:X, not A:X. 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 analyze 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 for the ISP to accept routes from the site for the site's multiple prefixes. (The ISP does not need to propagate these site routes into the broader Internet routing fabric.) Then RPF-based ingress filtering checks will succeed, because the ISP will have routes for all the site's prefixes instead of just the site prefix assigned by the ISP itself. This solution requires that the site communicates its 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 requires a higher level 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 Shipworm. 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 or the Huitema, Draves [Page 6] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 Shipworm anycast address; this will imply a negotiation with the provider of the IPv4 service. 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 originating in the generic routing domain and bound to an external 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. In the most complex set up, each router of the site would maintain as many parallel routing tables as there are valid source prefixes, Huitema, Draves [Page 7] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 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 external address would perform a source address check before forwarding the packet on one of its outgoing interfaces; if the source address check fails, the packet would be "tunneled" to the appropriate site-exit 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 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. Huitema, Draves [Page 8] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 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 appropriate site-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 to ensure that subsequent 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. To implement source address discovery, the hosts would have to introduce a "preferred source prefix" parameter in the "destination cache" mentioned in the Neighbor Discovery standard [RFC2461]. 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. There will however be cases in which the prefix is learned after the source address is already selected. In these cases, the host could insert in the packet a "home address" option that carries the intended source Huitema, Draves [Page 9] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 address, as specified in [MOBILIP6]; the IPv6 source address will be set to the available interface address that matches the preferred source prefix. As for path MTU discovery, source address discovery requires that the hosts receive some information from the network, presumably in the form of an "incorrect source address" ICMP error; the error message will have to contain information about the packet that triggered the error, and also information about the source address prefix that should be used to pass the source address check. In the absence of an explicit ICMP message, the hosts would have to rely on a trial-and-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 can 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. Alternatively, the host can use a Routing Header and specify the site-exit router as an intermediate destination. Comparing "exit router discovery" and "source address discovery", both solutions require resources in the host. Exit router discovery enables hosts to actually specify the point of exit from the site, thus giving them a greater amount of "policy control". Source address discovery allows hosts to exploit fully-asymmetric paths to optimize communication. We should note that neither "source address discovery" nor "exit router discovery" are implemented in current hosts. We must meet the requirement expressed in [MULTI6RQ] 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 Huitema, Draves [Page 10] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 can route the packet to an alternative exit. Another way to pass the source address check is to modify the packet, which could in theory be done by replacing the source address, by inserting a "home address" header, 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. It introduces all the NAT problems, like updating transport-level checksums and failing when IPsec is employed. One could preserve the source address information by inserting the "home address" option defined in [MOBILIP6] before rewriting the source address. After the insertion of the option, the outgoing parameter will have the following values: * IPv6 source address: address of the site egress interface, * IPv6 destination address: from initial packet, * IPv6 payload type: "destination option", * destination option, next header: payload type of initial packet, * destination option length: length of option, as per [RFC2640], * home address value: source address of initial packet. According to [MOBILIP6], the host which receives the packet with the home address option will behave exactly as if it received a packet from the initial source address. This is marginally better than rewriting the source address, because it does not impact upper-layer protocols or applications. However, it still fails when IPsec is employed and changing the size of a packet disrupts PMTU discovery. An alternative to using the home address option would be to encapsulate 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." This alternative is probably easier to implement than the insertion of a destination option; in particular, routers don't have to be concerned with the fact that there may already be a destination option in the incoming packet. It creates a slightly larger overhead, 40 bytes instead of 24. Introducing encapsulation like this has a serious problem: The correspondent host is not expecting to receive an encapsulated packet. Most implementations will not promiscuously decapsulate and process the inner packet in the absence of a tunnel interface that matches the outer header. 4.5 Comparison of the site exit solutions Huitema, Draves [Page 11] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 The four solutions that we have reviewed have different advantages and inconveniences. The 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 prefix 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 unworkable 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: the destination host is probably not willing to accept the encapsulated packet. 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. Exit router discovery or source address discovery would be 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 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 either be sent directly to the exit router appropriate to the source address or sent with the source address appropriate to the exit router. A single ICMP message can let the host choose either option. Huitema, Draves [Page 12] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 5 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 local failures. We will then present a list of host improvements that would gradually enable hosts to take full advantage of multihoming. 5.1 Resolving the site exit issue In line with the analysis presented in the previous section, our recommendation is to enable multihoming by either relaxing the source address checks, or by establishing tunnels between the site exit routers. The tunneling is complemented by the sending of an "exit redirection" ICMP message when appropriate. 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. 5.1.1 Site exit anycast address The proposed solution is to compose the site exit anycast address according to the rule specified in [RFC2526], by combining the 7 bit site exit anycast identifier with the subnet prefix. According to [RFC2526], the composition depends on the length L of the subnet prefix. If the prefix is 64 bit long, then the address is composed as: | 64 bits | 57 bits | 7 bits | +-------------------------------+------------------+------------+ | site prefix | 1111110111...111 | anycast ID | +-------------------------------+------------------+------------+ | interface identifier field | If the prefix length is not 64 bit, then there is no need to comply with the EUI-64 syntax, and the prefix should be: | L bits | 121-L bits | 7 bits | +-------------------------------+------------------+------------+ | site prefix | 1111111...111111 | anycast ID | +-------------------------------+------------------+------------+ | interface identifier field | The site exit anycast address solution assumes that all of the sites exit routers know the length L of the various site prefixes; in practice, we expect that all site prefixes will have the same length. Huitema, Draves [Page 13] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 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. 5.1.2 Site-exit redirection ICMP message Routers send site-exit redirect packets to inform a host that its packets are being tunneled to another site-exit router, so that if the host wishes to take action it can avoid this inefficiency. The host might tunnel or source-route the packet to an appropriate site- exit router, or the host might choose a source address appropriate to the redirecting site-exit router. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Reserved | Redirection Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Preferred Source Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address An address assigned to the router from which this message is sent. The Source Address SHOULD be a site-local address. Destination Address The Source Address of the packet that triggered the site-exit redirect. 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 Huitema, Draves [Page 14] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 Code 0 Checksum The ICMP checksum. See [ICMPv6]. Prefix Length 8-bit unsigned integer. The number of leading bits in the Preferred Source Prefix that are valid. The value ranges from 0 to 128. Redirection Lifetime The number of seconds during which the redirection should remain in effect, expressed as an unsigned 16-bit integer, in network byte order. Preferred Source Prefix An IP address prefix. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the Prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver. 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. A host that receives a site-exit redirection message may react in several ways. First, the host may ignore the site-exit redirect. The host's packets will continue to take a suboptimal path. ICMP rate- limiting on the router will prevent the router from continually sending site-exit redirect errors. The host SHOULD ignore the site- exit redirect if the message's Source Address is not site-local, unless the message is authenticate via IPsec. Second, the host may use the preferred source prefix in the message to choose a different source address, appropriate to the site-exit for this destination. The host may use a Home Address option to preserve its original choice of source address. Third, the host may tunnel or source-route the packet to a different site-exit router, appropriate to its source address. The host can derive a site-exit anycast address from its source address and tunnel or source-route the packet, using the site-exit anycast address as an intermediate destination. 5.1.3 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 amount of checking will vary depending on the exit link. If the provider Huitema, Draves [Page 15] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 has agreed to relax source address checking, the router will be configured to not do any checking at all; if the provider is expected to enforce a source address check, the site exit router must do the check 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, and the router may issue a "site exit redirection" ICMP message. 5.2 Rapid reaction to failures 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" lifetime 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 sites, we propose to use the "router renumbering" mechanism to maintain an up-to-date list of available prefixes across the site's routers. 5.2.1 Use of "Router advertisements" The router advertisement messages are defined in [RFC2461]; their use for address configuration is defined in [RFC2462]. As specified in [RFC2461], the router advertisements include a variable number of Prefix Information parameters. Each Prefix Information parameter specifies: * an address prefix value, * 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 because the corresponding ISP connection is broken, routers SHOULD advertise a zero preferred lifetime for that prefix. In conformance with section 5.5.4 of [RFC2461], the hosts will deprecate the formerly preferred addresses when their preferred lifetime is set to zero. They will not use the deprecated addresses in new communication if an alternate (non-deprecated) address is available and has appropriate scope. Huitema, Draves [Page 16] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 Manipulating the preferred lifetime only solves part of our problem, since according to [RFC2461] 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 host improvements that are described in a later section. 5.2.2 Use of "Router Renumbering" To advertise a zero preferred lifetime for a specific prefix, the site's routers must be able to learn about that prefix. A possibility is to use the "Router renumbering" protocol [RFC2894] to pass this information. The protocol allows an authorized agent, in that case the site exit router, 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. 5.3 Host improvements To take advantage of host centric multihoming, we will have to improve the handling of multiple addresses in the hosts. The handling will be focused on three areas: destination selection algorithms, source selection algorithms, and adaptive transports or applications. 5.3.1 Destination address selection [DASIP6] specifies several rules for destination address selection. The lowest-priority rules, applied when there is no better way to distinguish between two destination addresses, call for first using the destination address with longest prefix matching a potential source address, and if all else is equal, leaving the destination addresses in the order that they were learned (eg from DNS). These two rules may be replaced with more sophisticated algorithms. For example, the host can take advantage of information learned from past transmissions or from other hosts. 5.3.2 Source address selection Similarly, [DASIP6] specifies several rules for source address selection, with a longest-matching-prefix tiebreaker. Instead of using longest-matching-prefix, a more sophisticated algorithm could take into account the same kind of information that is also used in destination address selection. Current implementations of TCP, when the application has not bound a particular source address, will only try one source address when establishing a connection. It would be better to try multiple source addresses, perhaps in parallel. For example, the host might send multiple SYNs with different source addresses and wait for the first SYN-ACK reply to choose among them. Huitema, Draves [Page 17] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 5.3.3 Combined source and destination address selection Many host implementations of IPv6 perform destination address selection first, and then source address selection. This is unfortunate for multiple reasons. Since hosts are much more likely to gain knowledge about their local connections than about conditions at a remote location, they are much more likely to develop accurate ranking of source addresses than destination addresses. Furthermore, rather than have the application sequentially try different destination addresses, it would be better to try them in parallel. We should encourage the development of new host APIs that let the network stack choose both the destination and source address. This requires an evolution of the "socket" interface. 5.3.4 Site-exit redirection Hosts can be programmed to process site-exit redirect message from routers and either send packets via an appropriate site-exit router (using the site-exit anycast address) or change their choice of source address. The potential thread of site-exit redirection is small. First, the site-exit redirect should only be processed if it is directly protected by a security association or if it has a site-local source address, ie, it originated within the site. Unlike the usual redirect message, the site-exit redirect does not contain a new intermediate destination address. Instead, hosts algorithmically derive the site-exit anycast address. Hence the site-exit redirect message can not be used to redirect traffic to a destination of an attacker's choosing. At worst the attacker can cause unnecessary work on the host and in the network, by causing some tunneling or source-routing to occur that would otherwise have been unnecessary. As a consequence, packets may take a different path. The site-exit router might also affect the host's choice of source address, and as a consequence return packets may take a different path. Since site exit discovery is a routing optimization, hosts should balance the routing gain with the possible security risk. 5.3.5 Transport connection survivability To survive link failures, transport and applications will have to be able to use several IP addresses over the course of a connection. This is already enabled by protocols such as SCTP. It can also be retrofitted under existing protocols such as TCP by using Huitema, Draves [Page 18] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 "redirection" code developed for mobility solutions. For example, the "Binding Updates" defined in [MOBILIP6] can be used to propose transmission to a new address, as soon as the local host detects that the preferred lifetime of the current source address has expired. However, this solution does not handle the simultaneous failure of both side's access links because in that situation the Binding Updates will not get through. 5.3.6 Name service improvements The router advertisements provide a timely mechanism by which hosts can learn the list of valid and preferred source addresses. The hosts can be upgraded to use the dynamic DNS update mechanism, to ensure that only their "preferred" addresses are listed in the DNS. This mechanism will limit the extent of the "trial and error" failure mode of destination selection mentioned in section 3.1. The dynamic DNS update mechanisms is compatible with the AAAA record format defined in [RFC1886]. 6 Evaluation of Host centric solution and Multihoming Requirements The MULTI6 working group has elaborated a list of requirements for a multi-homing solution that is detailed in [MULTI6RQ]. In this section, we will review how the host centric approach to IPv6 multihoming meets these requirements, which are distributed in two subsections: matching the capabilities of IPv4 multihoming, and meeting additional requirements. 6.1 Capabilities of IPv4 Multihoming IPv4 multihoming is discussed in [MULTI6V4]. The host centric approach to IPv6 multihoming provides similar or better capabilities. 6.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. Huitema, Draves [Page 19] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 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 requirements 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. 6.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. 6.1.3 Performance Performance enhancements can be obtained by appropriate development if destination address selection and source address selection algorithms. 6.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. 6.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 [RFC2894]. 6.1.6 Transport-Layer Survivability Transport layer survivability is provided if the hosts implement a minimal set of enhancements, i.e. the sending of binding updates, as discussed in section 4.3. Huitema, Draves [Page 20] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 Following a re-homing event, the "preferred lifetime" update guarantees that new transport-layer sessions can be adequately created. 6.2 Additional Requirements 6.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. 6.2.2 Impact on Routers The solution requires two changes to IPv6 router implementations. In order to avoid the problems caused by ingress filtering and filtering, site exit routers should implement the "home address insertion" procedure. 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. 6.2.3 Impact on Hosts The solution does not destroy IPv6 connectivity for a legacy host implementing [RFC2373], [RFC 2460], [RFC2553] and other basic IPv6 specifications current in June 2001. 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, as well as a "binding update" solution for the survival of transport connections. 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. 6.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. Huitema, Draves [Page 21] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 6.2.5 Operations and Management It is possible to monitor and configure the multihoming system. 7 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. 8 IANA Considerations This document requests allocation by IANA of a new ICMPv6 message type (section 5.1.2), and of an IPv6 anycast identifier (section 2.5). 9 Copyright The following copyright notice is copied from RFC 2026 [Bradner, 1996], Section 10.4, and describes the applicable copyright for this document. Copyright (C) The Internet Society XXX 0, 0000. 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 10 Intellectual Property The following notice is copied from RFC 2026 [Bradner, 1996], Huitema, Draves [Page 22] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 Section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document. 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 other 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 implementers 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. 11 Acknowledgements This memo incorporates text from a previous draft submitted by Richard Draves. The authors would like to acknowledge the contributions of Bernard Aboba, Dave Thaler, and Brian Zill. 12 References [RFC2373] R. Hinden, S. Deering. "IP Version 6 Addressing Architecture." RFC 2373, July 1998. [RFC2460] S. Deering, R. Hinden. "Internet Protocol, Version 6 (IPv6), Specification." RFC 2460, December 1998 [RFC2461] T. Narten, E. Nordmark, W. Simpson. "Neighbor Discovery for IP Version 6 (IPv6)." RFC 2461, December 1998. [RFC2462] S. Thomson, T. Narten. "IPv6 Stateless Address Autoconfiguration." RFC 2462, December 1998. [RFC2526] D. Johnson, S. Deering. "Reserved IPv6 Subnet Anycast Addresses." RFC 2526, March 1999. [RFC2553] R. Gilligan, S. Thomson, J. Bound, W. Stevens. "Basic Socket Interface Extensions for IPv6." RFC 2553, March 1999. [RFC2894] M. Crawford, "Router Renumbering for IPv6", RFC 2894, August 2000. Huitema, Draves [Page 23] INTERNET-DRAFT Host-Centric IPv6 Multihoming July 12, 2001 [MULTI6RQ] Requirements for IP Multihoming Architectures, Work in progress. [MULTI6V4] IPv4 Multihoming Motivation, Practices and Limitations, Work in progress. [MOBILIP6] D. Johnson, C. Perkins. "Mobility Support in IPv6." Work in progress. [RFC2267] P. Ferguson, D. Senie. "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing." RFC 2267, January 1998 [RFC2874] M. Crawford, C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000. [RFC1886] S. Thomson, C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, December 1995. [DASIP6] R. Draves, "Default Address Selection for IPv6", Work in progress. 13 Author's Addresses Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Email: huitema@microsoft.com Richard Draves Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Email: richdr@microsoft.com Huitema, Draves [Page 24]