INTERNET DRAFT C. Huitema, R. Draves <draft-huitema-multi6-hosts-01.txt> Microsoft Expires December 24, 2002 June 24, 2002 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 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, which we analyze in detail. 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 interface 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- Huitema, Draves [Page 1]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 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, which we analyze in detail. 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. 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 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.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. 2.5 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 Huitema, Draves [Page 2]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 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.6 Site exit anycast identifier A 7 bit anycast identifier whose value is XX. [TBD IANA] 2.7 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 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 Huitema, Draves [Page 3]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 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 selects a source address associated to that interface. When the hosts 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". 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. 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 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 Huitema, Draves [Page 4]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 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 3.5 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. 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 Huitema, Draves [Page 5]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 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 be 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 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 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" Huitema, Draves [Page 6]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 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, 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 Huitema, Draves [Page 7]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 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. 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 Huitema, Draves [Page 8]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 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. 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 [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 would have to insert in the packet an "home address" option that carries the intended source address, as specified in [MOBILIP6]; the IPv6 source address will be set to the 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, 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 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. 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 Huitema, Draves [Page 9]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 control"; and it does not require third parties to understand and accept an "home address" option. 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 can route the 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, 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. One could preserve the 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. 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, Huitema, Draves [Page 10]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 40 bytes instead of 24. 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. 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 Huitema, Draves [Page 11]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 "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. 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.2 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.2.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. 5.2.2 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. Huitema, Draves [Page 12]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 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 ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address An address assigned to the router from which this message is sent; SHOULD be a site local address whenever one is available. 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 [ICMPv6]. 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 Huitema, Draves [Page 13]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 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. 5.2.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 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.3 Rapid reaction to 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 anay given time. Huitema, Draves [Page 14]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 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. 5.3.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 routers MUST advertise a null preferred lifetime for that prefix. In conformance with section 5.5.4 of [RFC2461], 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 [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.3.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 [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. 5.4 Host improvements In order 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 Huitema, Draves [Page 15]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 applications. 5.4.1 Destination address selection Destination selection algorithms can vary from the simplest, e.g. pick an address at random from a list, to the most sophisticated, e.g. maintain a routing table based on information learned from routers, past transmissions or other hosts. 5.4.2 Source address selection Source destination algorithms can also vary from the simplest to the more complex. A basic algorithm is to pick a source address at random, from the list of available source addresses with an adequate scope and a non zero preferred life time. More sophisticated algorithms can take into account the same kind of information that is also used in destination address selection. 5.4.3 Combined source and destination address selection Many host implementations of IPv6 perform destination address selection first, and then source address selection. This is questionable, since hosts are much more likely to gain knowledge about their local connections than about conditions at a remote location, and thus are much more likely to develop accurate ranking of source addresses than destination addresses. A likely evolution is for hosts to invert the order of the selection, selecting the source address first, and then the destination address; this may require an evolution of the "socket" interface. 5.4.4 Exit router discovery 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. 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 ICMP message: * check that the IPv6 source address is a site local address, or at a minimum that it corresponds to a local prefix; * check that the prefix length has a realistic value, e.g. at least 48 bits; Huitema, Draves [Page 16]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 * 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. 5.4.5 Transport connection survavibility In order 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 could be retrofit under existing protocols such as TCP if we use "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.5.4.6 5.5 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 17]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 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. Following a re-homing event, the "preferred lifetime" update guarantees that new transport-layer sessions can be adequately Huitema, Draves [Page 18]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 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. 6.2.5 Operations and Management Huitema, Draves [Page 19]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 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. 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], 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 Huitema, Draves [Page 20]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 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. 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. [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. [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. Huitema, Draves [Page 21]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 [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. 1) 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 22]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 Table of Contents: 1 Introduction .................................................... 1 2 Notations ....................................................... 2 2.1 Requirements language ......................................... 2 2.2 Reference topology ............................................ 2 2.4 Site exit router .............................................. 2 2.5 Ingress filtering ............................................. 2 3 Host-Centric IPv6 Multihoming issues ............................ 3 3.1 Destination address selection ................................. 3 3.2 Source address selection ...................................... 3 3.3 The site exit issue ........................................... 4 3.5 Rapid reaction to topology changes ............................ 5 4 Analysis of solutions to the site exit issue .................... 5 4.1 Relaxing the source address checks ............................ 5 4.2 Source address dependent routing .............................. 6 4.3 Source address selection by the host .......................... 8 4.4 Packet rewriting at exit router ............................... 10 4.5 Comparison of the site exit solutions ......................... 11 5 Proposed solution ............................................... 12 5.2 Resolving the site exit issue ................................. 12 5.2.1 Site exit anycast address ................................... 12 5.2.2 Site exit redirection ICMP message .......................... 12 5.2.3 Tunneling to the appropriate exit ........................... 14 5.3 Rapid reaction to failures .................................... 14 5.3.1 Use of "Router advertisements" .............................. 15 5.3.2 Use of "Router Renumbering" ................................. 15 5.4 Host improvements ............................................. 15 5.4.1 Destination address selection ............................... 16 5.4.2 Source address selection .................................... 16 5.4.3 Combined source and destination address selection ........... 16 5.4.4 Exit router discovery ....................................... 16 5.4.5 Transport connection survavibility .......................... 17 6 Evaluation of Host centric solution and Multihoming Requirements 17 6.1 Capabilities of IPv4 Multihoming .............................. 17 6.1.1 Redundancy .................................................. 17 6.1.2 Load Sharing ................................................ 18 6.1.3 Performance ................................................. 18 6.1.4 Policy ...................................................... 18 6.1.5 Simplicity .................................................. 18 6.1.6 Transport-Layer Survivability ............................... 18 6.2 Additional Requirements ....................................... 19 6.2.1 Scalability ................................................. 19 6.2.2 Impact on Routers ........................................... 19 6.2.3 Impact on Hosts ............................................. 19 6.2.4 Interaction between Hosts and the Routing System ............ 19 6.2.5 Operations and Management ................................... 19 7 Security Considerations ......................................... 20 8 IANA Considerations ............................................. 20 9 Copyright ....................................................... 20 10 Intellectual Property .......................................... 20 Huitema, Draves [Page 23]
INTERNET-DRAFT Host-Centric IPv6 Multihoming June 24, 2002 11 Acknowledgements ............................................... 21 12 References ..................................................... 21 13 Author's Addresses ............................................. 22 Huitema, Draves [Page 24]