Network Working Group M. Bagnulo Internet-Draft A. Garcia-Martinez Expires: August 26, 2003 I. Soto UC3M February 25, 2003 Application of the MIPv6 protocol to the multi-homing problem draft-bagnulo-multi6-mnm-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 26, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This note attempts to describe how to apply the MIPv6 protocol to provide fault tolerance to transport layer connections established between a multi-homed host and other hosts in the Internet. Specifically, this note addresses the usage of MIPv6 signaling messages to convey information about alternative address to be used when an outage occurs. Additionally, possible mechanisms to detect failures affecting the currently used path are explored. Bagnulo, et al. Expires August 26, 2003 [Page 1] Internet-Draft Application of MIPv6 to multi-homing February 2003 1. Introduction Several times it has been claimed that the MIPv6 [1] protocol could be a useful tool to deal with the multi-homing problem. A few years ago, the application of MIPv6 protocol to the multi-homing problem was proposed by F. Dupont in [2]. Since that time, the MIPv6 protocol has been greatly improved and substantial modifications have been introduced, particularly in the security aspects of the protocol. Recently, C. Huitema suggested in [3] that mobility extensions could be used to convey alternative address information of multi-homed hosts. This note attempts to complement previous work by providing a complete proposal of how to apply the MIPv6 protocol to provide fault tolerance to transport layer connections established between a multi-homed host and hosts in the Internet. Specifically, this note addresses the usage of MIPv6 signaling messages to convey information about alternative address to be used when an outage occurs. Additionally, possible mechanisms to detect failures affecting the currently used path are explored. Bagnulo, et al. Expires August 26, 2003 [Page 2] Internet-Draft Application of MIPv6 to multi-homing February 2003 2. Acronyms MHH: Multi-Homed Host CN: Correspondent Node BU: Binding Update BA: Binding Acknowledgment HoA: Home Address CoA: Care-of Address HoTI: Home Test Init HoT: Home Test CoTI: Care-of Test Init CoT: Care-of Test PA: Provider Aggregatable SEAA: Site Exit Anycast Address SEAAA: Site Exit Anycast Address corresponding to ISPA SEAAB: Site Exit Anycast Address corresponding to ISPB Bagnulo, et al. Expires August 26, 2003 [Page 3] Internet-Draft Application of MIPv6 to multi-homing February 2003 3. Application Scenario +-----+ |Host1| | CN | +-----+ | ... | _______|_______________________________________ | | | | | | |______________________________________________| | | | | | link2 link1 | | | +---------------+ +---------------+ | ISPA | | ISPB | | PA::/nA | | PB::/nB | +---------------+ +---------------+ | | | | | | link3 link4 __|____________________________|___ | RA RB | | +-----+ | |Multi-homed end-site |Host2| | |PA:Site::/48 | MHH | | |PB:Site::/48 +-----+ | |___________________________________| The application scenario consists of a multi-homed end-site that obtains global connectivity through two (or more) ISPs i.e. ISPA and ISPB. Since the end-site is multi-homed and provider aggregatable addresses are being used, the site has obtained two address ranges: one delegated from ISPA address range i.e. PA:Site::/48 and the other one from ISPB address space i.e. PB:Site::/48. Furthermore, in order to benefit from multi-homing, hosts within the site have to be Bagnulo, et al. Expires August 26, 2003 [Page 4] Internet-Draft Application of MIPv6 to multi-homing February 2003 reachable through both ISPs. This implies that hosts have to configure one address from each ISP address range that the site has obtained. For instance, in the case of Host2, two addresses are configured i.e. PA:Site:Host2 and PB:Site:Host2. So, this configuration provides some Fault Tolerance capabilities since Host1 can reach Host2 through ISPA, using as destination address PA:Site:Host2 and it can also reach it through ISPB using as destination address PB:Site:Host2. This means that if there is an outage in one of the ISPs, ISPA for instance, Host1 can still reach Host2 using the alternative address i.e. PB:Site:Host2. However, this configuration does not allow the preservation of established connections through an outage event. This is the result of following constraints: - Most connections established at the transport level and above identify the endpoints involved in the communication by their IP addresses, imposing that they must remain unchanged during the lifetime of the connection. - In order to preserve aggregation benefits, Provider Aggregatable addresses delegated to the end-site by an ISP are to be routed toward the site through this ISP, so that it routes them toward the final destination. In the application scenario considered, addresses containing the prefix PA::/nA are routed to ISPA, who then routes them to the end-site considered. These constraints imply that if a connection between Host1 and Host2 is established using PA:Site:Host2 as address for Host2, packets flowing to Host2 will be routed through ISPA and only through ISPA. Then, if during the lifetime of this connection an outage occurs in ISPA, the connection will be dropped, even if a path between Host1 and Host2 is available. This is so because packets whose final destination address contains the PA::/nA prefix have no available route to Host2, since they can not be routed through ISPB and packets addressed to the alternative destination of Host2 (PB:Site:Host2) are not recognized by transport and uppers layers as belonging to the connection established using PA:Site:Host2. This note presents a mechanism for preserving established communications during an outage based in the MIPv6 protocol. Bagnulo, et al. Expires August 26, 2003 [Page 5] Internet-Draft Application of MIPv6 to multi-homing February 2003 4. Application of the MIPv6 protocol to the multi-homing problem 4.1 Required capabilities In order to preserve established connections throughout an outage, the following capabilities are required: 1- A path failure detection mechanism, that enables end-hosts to detect outages in the path that is currently being used. When a failure is detected a recovery mechanism, such as routing packets through an alternative path, is triggered. 2- A protocol to inform the other end of the communication about the alternative path that is to be used. Since Provider Aggregatable address are used, alternative paths (alternative ISPs) are represented by alternative destination addresses. So the protocol is used for conveying alternative destination address. 3- A mechanism that allows packets carrying the alternative address as destination address to be recognized as belonging to the established connection. In order to be transparent to transport layer and above, such mechanism must restore the original destination address when the final destination is reached. 4- Tools to ensure compatibility with ingress filtering mechanisms. Since an alternative ISP will be used when a outage occurs, packets carrying the original source address would be incompatible with ingress filtering mechanisms. 4.2 Overview MIPv6 protocol provides the tools needed to satisfy all the above requirements, as it will presented next. In order to apply the MIPv6 protocol to the considered scenario, the first step is to map the multi-homing scenario to a mobility scenario. Since the multi-homed host (MHH) has the need to use multiple alternative addresses in a given connection, it will have the role of mobile node, and the node that it is communicating with will have the role of Correspondent Node (CN). It is assumed that Correspondent Nodes have support for route optimization. Home Agent capabilities are not required. 4.2.1 Required capability #2 The most natural application of the MIPv6 protocol seems to be the usage of Binding Update (BU) messages to inform the Correspondent node that an alternative address is to be used for the established Bagnulo, et al. Expires August 26, 2003 [Page 6] Internet-Draft Application of MIPv6 to multi-homing February 2003 communication, fulfilling requirement #2. So, when the MHH detects that the currently used path becomes unavailable, it would send a Binding Update message to the Correspondent Node, informing that an alternative address is to be used. In MIPv6 terminology, the original address would be the Home Address (HoA) and the new alternative address would be the Care-of Address (CoA). However, MIPv6 security requirements impose the return routability procedure to enable the required BU message authorization. Such procedure implies the exchange of Home Test Init (HoTI) and Home Test (HoT) messages using the HoA and the exchange of Care-of Test Init (CoTI) and Care-of Test (CoT) messages using the CoA. Such exchanges are designed to verify that the host reachable through both the CoA and the HoA is the same. This means that the MHH needs to be reachable through both paths when these exchanges are performed, implying that these exchanges can not be performed successfully once an outage has occurred. So, the return routability procedure should be performed when a connection with a new CN is established allowing that this connection is protected during its complete lifetime. However, nonces used for the generation of the home keygen token and the care-of keygen token have a limited lifetime, imposing periodical return routability checks, in order to ensure that valid BU authorization information is available when an outage occurs. The time constraints imposed by MIPv6 are: 1- It is recommended by MIPv6 specification that nonces remain valid for at least MAX_TOKEN_LIFE seconds i.e. 210 seconds after it has been used to construct a return routability message. 2- MIPv6 also specifies that the CN must not accept nonces beyond MAX_NONCE_LIFE seconds i.e. 240 seconds after their first use. These constraints impose the performance of the the return routability procedure every MAX_TOKEN_LIFE minus the time required to perform the procedure, which would include the Round Trip Time (RTT) and the processing time. If the typical value used for TCP connection establishment timeout (75 seconds) is accepted as a reasonable upper bound to the RTT, and the processing time is considered to be negligible compared to the RTT considered, the return routability procedure needs to be performed every 135 seconds. 4.2.2 Required capability #3 Once that the availability of the information needed to authorize BU messages is guaranteed, the MHH is prepared to re-route its connections through an alternative address when an outage occurs. So, when the outage is detected, the MHH will send a BU message to the CN, informing that a new address (CoA) is to be used. Then, the CN Bagnulo, et al. Expires August 26, 2003 [Page 7] Internet-Draft Application of MIPv6 to multi-homing February 2003 will address packets to the new CoA. However, packets addressed to CoA have to be recognized as belonging to the established connection. This can be achieved by using the Type 2 Routing Header specified in MIPv6, in the same way that it is used for supporting mobility. That is, after receiving a valid BU, the CN addresses packets to the MHH to the new CoA, and it also includes a Type 2 Routing Header carrying the HoA. The resulting behavior is that when these packets reach the MHH through the CoA, the Routing Header is processed and the HoA is restored and packets are presented to the transport and above layers as being addressed to the HoA, preserving established connections. 4.2.3 Required capability #1 Additionally, a failure detection mechanism that triggers the generation of BU messages is required to provide a complete solution. A possible approach for this is to rely on transport and/or application layer capabilities. Some transport protocols such as TCP provide a reliable service, implementing time-out and retransmission of packets. When unreliable transport protocols are used, some applications provide recovery mechanisms that imply retransmission of lost packets. These retransmission events can be used as a failure indication to trigger the usage of an alternative address. However, this approach requires that the transport layer and/or applications inform the IP layer about retransmission events, imposing modifications to current implementations. Besides, some applications, such as interactive voice applications, do not employ packet recovery mechanisms. In these cases, an additional failure detection mechanism has to be provided, so that these applications can benefit from multi-homing. It is then deemed necessary to provide a failure detection mechanism. Such mechanism should be provided at the IP layer so that it is available for all applications and transport layers. An simple end-host path failure detection mechanism can be based on the exchange of keep-alive messages. Since this is a network layer mechanism, a possibility is the exchange of ICMP messages. For instance, ICMP echo request/reply can be used, profiting that most IP stacks already include ICMP functionality. This would imply that only MHH stacks need to be modified in order to provide the failure detection mechanism. Another possibility is the usage of HoTI/HoT messages. As it was mentioned above, return routability procedure needs to be performed periodically, implying message exchange between the MHH and the CN. However, in order to provide a failure detection mechanism, the message exchange frequency has to be increased not only because its period of 135 seconds may be deemed as unacceptable for certain Bagnulo, et al. Expires August 26, 2003 [Page 8] Internet-Draft Application of MIPv6 to multi-homing February 2003 applications, but because valid authorization information is required for sending the BU message. Since a failure is indicated by at least one keep-alive message lost, it is necessary that after such event valid BU authorization information is still available, which implies that the information acquired during the previous message exchange is still valid. Then, assuming that a failure is indicated by the lost of two consecutive keep-alive packets, HoTI messages have to be generated by the MHH every MAX_TOKEN_LIFE/3 seconds i.e. 70 seconds. Then if two HoTI messages are lost, that is, no reply is received 140 seconds after a HoTI was sent, a BU message is generated and an alternative route is used. Note that HoT replies are linked to HoTI requests by the home init cookie parameter. The simple mechanism presented provides the minimum required functionality while respecting the timing imposed by the return routability procedure parameters. Failure response time can be improved by increasing the message exchange frequency. Moreover, adaptive mechanism, such as the TCP time-out calculation mechanism can also be contemplated, as long as they respect the timing constraints imposed by MIPv6. However, it should be noted that these changes only need to be performed at the MHH, since the CN role is limited to reply messages generated by the MHH. This allows that multiple failure detection policies can be implemented without affecting interoperability. It should also be noted that only HoTI/HoT message exchange frequency need to be increased, since only the currently used path need to be tested. In the case where more than two paths are available, testing all the available paths may provide some valuable information at the time an outage occurs, since it would enable a more educated path selection. In this case, CoTI/CoT messages can be used to test alternative paths and compare them. However, in the case of dual homed sites, where only one alternative paths is available, this testing does not seem to provide relevant information. 4.2.4 Required capability #4 When a MHH has multiple PA addresses configured in its interface, source address selection implies the selection of the ISP to be used in the return path. Moreover, because of ISP ingress filtering mechanism, source address selection also imposes the ISP to be used in the forward path, requiring additional functionalities at the multi-homed site to guarantee the appropriate ISP selection as discussed in [3]. Besides, when host based path failure detection mechanisms are used, the only party that has the information needed for selecting the path to be used is the host itself. So, in order to guarantee the compatibility with ingress filtering mechanisms, the MHH can select the exit ISP by means of a Routing Header. In order to simplify ISP selection, the Site Exit Anycast Address defined in [3] can be used. Then, after performing source address selection, the MHH addresses packets to the Site Exit Router Anycast Address Bagnulo, et al. Expires August 26, 2003 [Page 9] Internet-Draft Application of MIPv6 to multi-homing February 2003 corresponding to the ISP that has assigned the address used as source address and it includes the final destination address in a Routing Header. It should be noted that the Site Exit Anycast Address is automatically deduced from the source address, so no additional configuration is required. Additional complexity results when an outage occurs. In this case, an alternative ISP is to be used for coursing packets. Source address filtering mechanisms of the alternative ISP precludes the flow of packets carrying the address originally used i.e. the HoA. However, the CN only recognizes packets as belonging to the established connection if they carry the original HoA. In order to overcome this issue, the Home Address Destination Option is to be used, so that the source address corresponding to the alternative ISP (i.e. the CoA) is carried in the Source Address field of the IPv6 header and the original address (i.e. the HoA) is carried within the Home Address Option. When the packet is received by the CN, it processes the Home Address Option and restores the HoA as the Source Address. Note that when including the Routing Header to perform exit ISP selection, Site Exit Anycast Address have to be selected according to the source address actually carried in the Source Address field of the IPv6 packet and has no relation with the HoA carried in a Home Address Option. 4.3 Resulting Behavior In this section, the complete operation of the solution in the application scenario is described. First of all, a communication is established between the MHH and the CN. This communication can be initiated by any of the parties. If the communication is initiated by the CN, it will first obtain at least one of the MHH's addresses, for instance using the DNS. If all the MHH's addresses are listed in the DNS, the CN will pick one and try to initiate the communication using this address. If a failure has occurred along the path, the attempt to initiate the communication will fail and the CN will try again with another address. Eventually, a packet from CN will reach MHH. In the application scenario, Host1 obtains PA:Site:Host1 and PB:Site:Host1 from the DNS. Then it will try to initiate the communication using PA:Site:Host1 and if this fails it will try using PB:Site:Host1 (this is an arbitrary choice). If the communication is initiated by the MHH, it will obtain CN's address, using for instance the DNS. Then, it will apply the source address selection algorithm which outcome will be the address to be Bagnulo, et al. Expires August 26, 2003 [Page 10] Internet-Draft Application of MIPv6 to multi-homing February 2003 used as source address when sending packets to the CN. The MHH attempts to communicate with the CN using the selected source address. In order to avoid that the ISP ingress filtering mechanism discarded this packet, MHH addresses the packet to the Site Exit Anycast Address of the ISP that assigned the source address selected and includes the CN address within a Routing Header.If a failure along the path has occurred, the communication will fail and MHH will try with another source address, so that the packet is coursed through an alternative ISP. In the application scenario, according to [3], Site Exit Anycast Addresses for ISPA is PA:Site:FFFF:FFFF:FFFF:FFFF:FFFF (Hereafter SEAAA) Site Exit Anycast Addresses for ISPB is PB:Site:FFFF:FFFF:FFFF:FFFF:FFFF (Hereafter SEAAB) Then, MHH will try first to send a first packet with: IPv6 Header Destination address: SEAAA Source address: PA:Site:Host2 Routing Header Type: 1 Address#1: Host1 If this packet fails, it will try with: IPv6 Header Destination address: SEAAB Source address: PB:Site:Host2 Routing Header Type: 1 Address#1: Host1 When the packet arrives to the corresponding site exit router, the Routing Header will be processed and the Destination Address will be set to Host1. Once that MHH starts sending packets to CN, different address roles Bagnulo, et al. Expires August 26, 2003 [Page 11] Internet-Draft Application of MIPv6 to multi-homing February 2003 have been set i.e. the address used as Source Address in the first packet flowing from MHH to CN will be the HoA and the other available addresses of MHH will be CoAs. It should be noted that these roles are assigned when the communication is established and they are not preassigned. This means that any address can be HoA or CoA. Moreover, a given address could be used as HoA in a communication with a given host and used as CoA in a communication with another one. In the application scenario, we suppose that the first packet flowing from MHH to CN has PA:Site:Host2 as source address, so that: PA:Site:Host2 is HoA and PB:Site:Host2 is CoA Once that the first packet is carried from MHH to CN, the MHH has to perform the return routability procedure in order to obtain valid authorization data. This data is to be used if an outage occurs to course packets using an alternative address. The return routability procedure consists in exchanging HoTI/HoT messages using the HoA and CoTI/CoT messages using CoA. These messages also have to include a Routing Header to select appropriate exit ISP. In the application scenario the following messages are exchanged: First MHH sends HoTI and CoTI messages: HoTI message IPv6 Header Destination Address: SEAAA Source Address: PA:Site:Host2 Routing Header Type: 1 Address#1: Host1 Mobility Header Type: HoTI Home Init Cookie: HCookie Bagnulo, et al. Expires August 26, 2003 [Page 12] Internet-Draft Application of MIPv6 to multi-homing February 2003 CoTI message IPv6 Header Destination Address: SEAAB Source Address: PB:Site:Host2 Routing Header Type: 1 Address #1: Host1 Mobility Header Type: CoTI Care-of Init Cookie: CCookie The CN replies sending HoT and CoT messages as follows: HoT message IPv6 Header Destination Address: PA:Site:Host2 Source Address: Host1 Mobility Header Type: HoT Home Init Cookie: HCookie (from HoTI message) Home Nonce Index: HNI Home Keygen Token: HKT CoT message IPv6 Header Destination Address: PB:Site:Host2 Source Address: Host1 Mobility Header Type: CoT Care-of Init Cookie: CCookie (from CoTI message) Care-of Nonce Index: CNI Care-of Keygen Token: CKT The goal of the CoTI/CoT message exchange is to maintain valid authorization data in case an outage occurs, so it is performed every 135 seconds. HoTI/HoT message exchange has two goals: first it provides valid Bagnulo, et al. Expires August 26, 2003 [Page 13] Internet-Draft Application of MIPv6 to multi-homing February 2003 authorization information in case an outage occurs and second it is used as a path failure detection mechanism. This second goal imposes that the HoTI/HoT exchange has to be performed every 70 seconds. Note that HoTI-HoT message correlation is detected using the Home Init cookie value. If no outage occurs, the communication continues as it is, and HoTI/ HoT and CoTI/CoT messages exchanges continue until the communication is finished. The only difference with packets flowing from a single-homed site is that they carry a Routing Header to perform exit ISP selection. Then, all packets flowing from the MHH to the CN carry the appropriate Routing Header to perform exit ISP selection according to the Source Address. In this case, packets carry PA:Site:Host2 as Source address so they carry SEAAA as Destination Address and they include Host1 in the Routing Header. If an outage occurs, it will be detected by the failure detection mechanism and an alternative path will be used. If two consecutive packets HoTI are not replied within 140 seconds after the first message was sent, a failure will be assumed. This sets a timeout of 140 seconds for the first CoTI packet and a timeout of 70 secs for the second message. IF this is the case, a BU message is sent, informing the CN that the CoA will be used to exchange packets. This BU message will carry authorization information obtained through the last successful HoTI/HoT and CoTI/CoT message exchanges. Timing is such, that this information is still valid when the BU reaches CN. In order to confirm that the BU was successfully processed, a Binding Acknowledgment (BA) is requested. According to MIPv6 specification, if no BA is received within INITIAL_BINDACK_TIMEOUT (i.e. 1 second), MHH retransmits the BU message increasing the sequence number until a response is received. The retransmission uses an exponential back-off process, doubling the timeout every time the BU is retransmitted until a BA is received or the timeout period reaches MAX_BINDACK_TIMEOUT (i.e. 32 seconds). Retransmission of BU using this timeout can continue indefinitely according to the specification. However, in this particular case, the authorization information has a limited lifetime, so it is useless to continue with the retransmissions once the information is no longer valid, which occurs MAX_NONCE_LIFE (240 seconds) after the nonce was used for creating the home keygen token. In the application scenario, suppose that two consecutive HoTI messages are not replied. In this case MHH send a BU message containing: Bagnulo, et al. Expires August 26, 2003 [Page 14] Internet-Draft Application of MIPv6 to multi-homing February 2003 BU message IPv6 Header Destination Address: SEAAB Source Address: PB:Site:Host2 Routing Header Type: 1 Address #1: Host1 Destination Option Extension Header Home Address Option Home Address: PA:Site:Host2 Mobility Header Type: Binding Update Acknowledge: set Home Registration: reset Link-Local Compatibility: Key Management Mobility Capability: ignored by CN Sequence #: S Lifetime: 0xffff Mobility Options Binding Authorization Data Option Authenticator: First (96, HMAC_SHA1(Kbm, Mobility Data)) Being: Mobility Data = PB:Site:Host2 | Host1 | Mobility Header Data Kbm = SHA1 (HKT | CKT) (from HoT and CoT messages respectively) Nonces Index Option Home Nonce Index: HNI (from HoT message) Care-of Nonce Index: CNI (from CoT message) CN replies sending a BA as follows Bagnulo, et al. Expires August 26, 2003 [Page 15] Internet-Draft Application of MIPv6 to multi-homing February 2003 BA message IPv6 Header Destination Address: PB:Site:Host2 Source Address: Host1 Routing Header Type: 2 Home Address: PA:Site:Host2 Mobility Header Type: Binding Acknowledgment Status: 0 (Binding Update Accepted) Key Management Mobility Capability: 0 Lifetime: granted by CN Sequence #: S (from BU) Mobility Options Binding Authorization Data Option Authenticator: First (96, HMAC_SHA1(Kbm, Mobility Data)) Being: Mobility Data = PB:Site:Host2 | Host1 | Mobility Header Data Once that the BU and BA messages have been exchanged, alternative ISP will be used to course packets between the MHH and the CN. Packets from the CN to the MHH will contain a Type 2 Routing Header in order to be routed through the alternative ISP: Packets from CN to MHH IPv6 Header Destination Address: PB:Site:Host2 Source Address: Host1 Routing Header Type: 2 Home Address: PA:Site:Host2 Packets from the MHH to the CN will carry the Home Address Destination Option and a Routing Header to select exit ISP: Packets from MHH to CN Bagnulo, et al. Expires August 26, 2003 [Page 16] Internet-Draft Application of MIPv6 to multi-homing February 2003 IPv6 Header Destination Address: SEAAB Source Address: PB:Site:Host2 Routing Header Type: 1 Address #1: Host1 Destination Option Header Home Address Option: PA:Site:Host2 The communication can continue using this route while the binding established at the CN remains valid. MIPv6 specification states that a binding established with CN using keys created using the return routability procedure must not exceed MAX_RR_BINDING_LIFE (i.e. 420 seconds). This is a major limitation for this application, since the binding can not be refreshed until the original route is restored and outages can last longer than 420 seconds. The possibility of increasing this value should be explored in order to adapt the protocol for this application. Anyway, since the usage of the alternative route imposes additional overhead because of the Home Address Option and the Type 2 Routing Header, the original route is to be used as soon as it is restored. So the original route has to be probed in order to detect when it is restored. This can be done sending HoTI messages, so that when a HoT message is received, the original path can be restored. Besides, it should be noted that no other alternative route can be used because no valid authorization data is available, since it can only be obtained through the exchange of HoTI/HoT messages through the original route. Because of this, using the failure detection mechanism to probe the alternative route does not seems to be relevant. Moreover, CoTI/CoT message exchange can be suspended until the original route is restored. If a HoT message is finally received, a BU message is sent in order to restore the original route. In the application scenario, MHH sends HoTI messages as follows Bagnulo, et al. Expires August 26, 2003 [Page 17] Internet-Draft Application of MIPv6 to multi-homing February 2003 HoTI message IPv6 Header Destination Address: SEAAA Source Address: PA:Site:Host2 Routing Header Type: 1 Address#1: Host1 Mobility Header Type: HoTI Home Init Cookie: HCookie' Until a HoT message is received from CN HoT message IPv6 Header Destination Address: PA:Site:Host2 Source Address: Host1 Mobility Header Type: HoT Home Init Cookie: HCookie' (from HoTI message) Home Nonce Index: HNI' Home Keygen Token: HKT' Then the MHH can send a BU message to restore the original route through ISPA. Bagnulo, et al. Expires August 26, 2003 [Page 18] Internet-Draft Application of MIPv6 to multi-homing February 2003 BU message IPv6 Header Destination Address: SEAAA Source Address: PA:Site:Host2 Routing Header Type: 1 Address #1: Host1 Mobility Header Type: Binding Update Acknowledge: reset Home Registration: reset Link-Local Compatibility: Key Management Mobility Capability: Sequence #: S' Lifetime: 0 (indicates deleting a binding) Mobility Options Binding Authorization Data Option Authenticator: First (96, HMAC_SHA1(Kbm, Mobility Data)) Being: Mobility Data = PA:Site:Host2 | Host1 | Mobility Header Data Kbm = SHA1 (HKT') (from HoT message) Nonces Index Option Home Nonce Index: HNI' (from HoT message) Care-of Nonce Index: 0 After receiving this message, the communication through the original route will be restored. Bagnulo, et al. Expires August 26, 2003 [Page 19] Internet-Draft Application of MIPv6 to multi-homing February 2003 5. Evaluation of the solution 5.1 Limitations The major limitation detected is that the lifetime of bindings established with the CN using keys created using the return routability procedure is limited to 420 seconds by the MIPv6 specification. This implies that the established connection is preserved for 7 minutes after the outage occurred. Since outages usually last longer than 7 minutes, this limitation drastically reduces the benefits provided by the solution. The possibility of extending the binding lifetime is to be explored if this solution is to be pursued. However, extending the binding lifetime may pose security problems, so this possibility has to be studied in great detail. Another detected limitation is that once that a path has failed and another one is being used, it is not possible to switch the communication to a third path. This is so because no valid authorization information is available, since the return routability procedure requires exchange of information using the HoA, which is in this case unavailable. Finally, a general limitation of the solutions based on hosts having multiple address is that it is difficult to implement policing. This is because hosts perform address selection and doing so they also select providers. The two last limitations are mostly relevant for large/medium sites. So, they reduce the scope of the solution to small sites. 5.2 Benefits The main benefit of the solution is its compatibility with the existent technology. For instance, changes needed are limited to hosts within the multi-homed site. Hosts in the outside of the site do not need to change almost anything in their implementation in order to communicate with a multi-homed site and benefit from multi-homing capabilities. The only change, if accepted, is the extension of maximum binding lifetime. Besides, this solution is compatible with PA scheme granting the scalability of the routing system. Finally, this solution does not requires that multi-homed sites to run BGP in contrast with many alternative solutions. This reduces the complexity of the solution and preserves the AS number space. Bagnulo, et al. Expires August 26, 2003 [Page 20] Internet-Draft Application of MIPv6 to multi-homing February 2003 5.3 Possible optimizations Multiple additional optimizations can be done to enhance the solution. Some are described next. MIPv6 specification includes the possibility of piggybacking binding related messages in data packets as a future extension of the protocol. This would reduce the overhead imposed by the solution. Other possible optimization that can be performed is related to the failure detection mechanism. The proposed mechanism provides minimum facilities. Improved algorithms can be proposed so that faster detection is provided. For instance adaptive mechanisms such as the ones used by TCP can be adopted. This document describes the constraints imposed by the MIPv6 specification. Any mechanism that honors these constraints is acceptable. Moreover, multiple mechanisms can be implemented in different hosts without compromising seamless interaction. Bagnulo, et al. Expires August 26, 2003 [Page 21] Internet-Draft Application of MIPv6 to multi-homing February 2003 6. Security Considerations The presented solution is based on the usage of the MIPv6 protocol, benefiting from MIPv6 security features. It should be assured by MIPv6 security experts that all the underlying assumptions of the mobility scenario remain valid. Additionally, the possibility of extending the lifetime of bindings established with the CN using keys created using the return routability procedure may introduce security hazards that need to be carefully considered. Bagnulo, et al. Expires August 26, 2003 [Page 22] Internet-Draft Application of MIPv6 to multi-homing February 2003 References [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", Internet Draft, Work in progress, May 2002. [2] Dupont, F., "Multihomed routing domain issues for IPv6 aggregatable scheme", Internet Draft, Work in progress(Expired), March 2000. [3] Huitema, C. and R. Draves, "Host-Centric IPv6 Multihoming", Internet Draft, Work in progress, June 2002. Authors' Addresses Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 EMail: marcelo@it.uc3m.es URI: http://www.it.uc3m.es/marcelo Alberto Garcia-Martinez Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 EMail: alberto@it.uc3m.es URI: http://www.it.uc3m.es/alberto Ignacio Soto Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 EMail: isoto@it.uc3m.es URI: http://www.it.uc3m.es/isoto Bagnulo, et al. Expires August 26, 2003 [Page 23] Internet-Draft Application of MIPv6 to multi-homing February 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). 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 Bagnulo, et al. Expires August 26, 2003 [Page 24] Internet-Draft Application of MIPv6 to multi-homing February 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Bagnulo, et al. Expires August 26, 2003 [Page 25]