Network Working Group M. Bagnulo Internet-Draft A. Garcia-Martinez Expires: December 31, 2001 A. Azcorra D. Larrabeiti UC3M July 2, 2001 Survey on proposed IPv6 multi-homing network level mechanisms draft-bagnulo-multi6-survey6-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 December 31, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document presents proposed solutions and tools related to IPv6 multi-homing. All presented proposals respect actual IPv6 routing architecture and current ISP address aggregation scheme, in particular, avoiding route injection to the DFZ. Besides, only network and transport level solutions are introduced, meaning that application level solutions are intentionally excluded. Bagnulo, et. al. Expires December 31, 2001 [Page 1] Internet-Draft Survey on multi-homing mecanisms July 2001 1. Introduction This document presents proposed solutions and tools related to IPv6 multi-homing. All presented proposals respect actual IPv6 routing architecture and current ISP address aggregation scheme, in particular, avoiding route injection to the DFZ. Besides, only network and transport level solutions are introduced, meaning that application level solutions are intentionally excluded. The aim of this study is to provide a compilation of the proposed solutions to serve as an input to multi6 working group discussion. Bagnulo, et. al. Expires December 31, 2001 [Page 2] Internet-Draft Survey on multi-homing mecanisms July 2001 2. Mechanisms description 2.1 IPv6 multi-homing with route aggregation The solution presented in "IPv6 multi-homing with route aggregation" [1] is intended to achieve the following objectives: o Redundancy provision in case of connection failure, in order to guarantee that the multi-homed site remains on line even if there is only one connection working properly. o Load sharing among available connections, so that both inbound and outbound traffic is balanced using the existing providers. o Simple management. Solution mechanism: ______________________________ | Internet | |______________________________| | | link1 | link5 | link2 ISPA--------------------- ISPB \ / link3 \______________________/ link4 | Multi-homed site | | PrefA:Prefsite::/n | |______________________| In the topology depicted in the figure above, the multi-homed site is connected to the Internet through two different ISPs (ISPA and ISPB). Besides, the considered site has obtained global addresses only from ISPA, which will be called primary ISP, so that the addresses contain PrefA (ISP based address aggregation is used). Note that in this solution, the multi-homed site needs only one global prefix. The propagation of routing information would be as follows: o The site propagates PrefA:Prefsite::/n to ISPA and ISPB through link3 and link4 respectively. o ISPB propagates PrefA:Prefsite::/n to ISPA through link5. Note that ISPB does NOT propagates routing information about PrefA:Prefsite::/n to the Internet. o ISPA propagates PrefA::/nA to the Internet through link1. Bagnulo, et. al. Expires December 31, 2001 [Page 3] Internet-Draft Survey on multi-homing mecanisms July 2001 With the described routing configuration, inbound traffic (traffic from the Internet to the site) will be routed towards ISPA through link1. Then ISPA performs load balancing through link3 and link5 (and therefore in this case, also through ISPB and link4). Outbound traffic (traffic from the site to the Internet) can be forwarded through ISPA (link3) or ISPB (link4) depending on the routing configuration of the site. In the case of failure, connectivity would be granted on the following situations: o If link3 fails, ISPA routes all traffic coming from the Internet towards the site through ISPB (link5 and then link4). Outbound traffic generated on site is routed through link4 to ISPB. o If link4 fails, ISPA does not route traffic to the site through ISPB (link5) so that all traffic is transmitted using link3. Traffic from the site to the Internet is exclusively routed through ISPA (link3). Mechanism evaluation Advantages o Neither new protocol nor new mechanism are needed, facilitating deployment. o Several global addresses per interface are no longer needed to obtain the benefits of the multi-homing architecture, which simplifies management on the site. o Provides fault tolerance if one of the links (link3 or link4) connecting to the ISP fails. o Preserves established TCP connections through link failure. o Allows load sharing, provided that local policies are capable to define which exit link to use. Concerns o Primary ISP is critical because its link to the Internet (link1) is the only used for inbound traffic. The mechanisms does not provide fault tolerance neither in case of primary ISP failure nor for Primary ISP Internet link failure. Another critical task that Primary ISP must implement is load sharing, deciding which link to Bagnulo, et. al. Expires December 31, 2001 [Page 4] Internet-Draft Survey on multi-homing mecanisms July 2001 use for inbound traffic. o The tasks that the primary ISP must complete imply a more complex ISP administration. o The mechanism is more efficient when a direct connection between ISPA and ISPB (link5) exists. If there is no such connection, more routing information has to be propagated, intermediate ISPs are involved, and less effective aggregation is achieved. o The mechanism requires coordination between ISPs, which may conflict with their commercial interests. Moreover, additional commercial issues may arise from the fact that there are two different roles appear, primary ISP and the rest. o Even though the mechanism allows load sharing, it does not provide any tool to perform ISP selection. Since the outbound link depends on site policies and the inbound link is determined by primary ISP, it is difficult to provide a coherent path for both directions of a given connection. o The mechanism to achieve load balance in the primary ISP for inbound traffic is not specified. 2.2 IPv6 multi-homing support at site exit routers. This mechanism is originally presented in "Scalable support for multi-homed multi-provider connectivity" [2] and further detail is given in "IPv6 multi-homing support at site exit routers" [3]. The intended goal of the mechanism is to maintain multi-homed site connectivity with the Internet even when some of the exit links are down. [3] explicitly expresses that this mechanism is not intended to provide link selection nor load balancing. Solution mechanism The solution is presented in the illustrated scenario: Bagnulo, et. al. Expires December 31, 2001 [Page 5] Internet-Draft Survey on multi-homing mecanisms July 2001 +----+ +----+ |ISPA|____________________ |ISPB| |BRA | __________________\___|BRB | +----+ / \ +----+ | /link3 link4 \ | link1 | / \ | link2 _|_/_________________________\__|_ | RA RB | | Multi-homed site | |PrefA:Prefsite PrefB:Prefsite| |__________________________________| In the configuration above, the multi-homed site is connected to the Internet through 2 ISPs (ISPA and ISPB) using link1 and link2 respectively. Each of the ISP has delegated an address space to the site: ISPA has delegated PRefA:Prefsite::/nA+n and ISPB has delegated PrefB:Prefsite::/nB+n. Besides, secondary links (link3 and link4) are established between the site and the ISPs. Link3 bonds the site exit router connecting with ISPA (RA) with the border router of ISPB (BRB). Link4 bonds the site exit router connecting with ISPB (RB) with the border router of ISPA (BRA). Secondary links are usually implemented as IP over IP tunnels. This tunnels may be built over existing physical links (link1 and link2) although the usage of additional physical links is recommended. In normal conditions, secondary links are advertised by the routing protocol with a very low priority, so that primary links (link1 and link2) are used. In case of failure, primary links are no longer advertised so secondary links become a valid option for the routers. Mechanism evaluation Advantages o Provides fault tolerance for ISP connecting link failure. o Preserves established TCP connections through link failure. o There is no need for new protocols or mechanisms. Concerns o Does not provide fault tolerance in case of ISP failure. o Does not provide tools for ISP selection for load sharing. Bagnulo, et. al. Expires December 31, 2001 [Page 6] Internet-Draft Survey on multi-homing mecanisms July 2001 o In case of long term failure, an additional mechanism is required for preventing the usage of the secondary link. This implies some mechanism to stop the usage of crashed ISP addresses as source address of outbound packets. o Implies more complex management due to the need of several global addresses per interface requiring the use of several ISPs. Another source of management complexity is the need of tunnel configuration. 2.3 Multi-homing with router renumbering This proposal is described in "Multihomed routing domain issues" [4]. It basically consists of the usage of Router Renumbering [5] and Router Advertising protocols to deprecate addresses in case of ISP failure. __________________________________________ | Internet | | | |__________________________________________| | | | | +----+ +----+ |ISPA| |ISPB| |BRA | |BRB | +----+ +----+ | | link1 | | link2 __|____________________________|__ | RA RB | | | | | | ------------------------------- | | | | | RC | | | | Multi-homed site | |PrefA:Prefsite PrefB:Prefsite| |__________________________________| In the depicted topology the multi-homed site obtains Internet connectivity using two ISPs (ISPA and ISPB). Each one of the ISPs has delegated an address space to the site, PrefA:Prefsite::/n and PrefB:Prefsite::/n respectively. In normal conditions, any device in the site that need to obtain internet access through both ISPs needs Bagnulo, et. al. Expires December 31, 2001 [Page 7] Internet-Draft Survey on multi-homing mecanisms July 2001 one global address of each address space, so that every interface is configured with at least two global addresses. Note that the inbound route is determined by the address used to refer to such device. In case of failure, the mechanism works as follows: Suppose that ISPA crashes. When an external host needs to communicate with any device of the site, it will query the DNS. The DNS will provide at least two addresses, as we stated before. If the ISPA delegated address (PrefA:Prefsite::host) is used, communication will fail, forcing the usage of the other address. When an internal host needs to establish a communication with an external host, internal routing configuration will course the outbound packet towards the ISP which is working properly. However if the packet source address belongs to ISPA address space, communication will not be established, because retuning packets will be routed towards the crashed ISP (ISPA). So, to ensure connectivity it is imperative to avoid the usage of addresses delegated by the crashed ISP, ISPA in our example. This can be achieved using the Router Advertising protocol and Router Renumbering protocol. In our site, the exit router connecting with ISPA (RA) would detect the failure and immediately would send a router advertising in order to deprecate ISPA delegated addresses. It would also use the Router Renumbering protocol to propagate the information about deprecation to other routers, such as RC, so that this addresses will not be used in any new connection. Mechanism evaluation Advantages o Provides stable configuration in case of long term ISP failure. Note that it provides ISP fault tolerance, not only link fault tolerance. o There is no need for any new protocol or mechanism. Concerns o It does not preserve established TCP connections. o It does not provide tools for ISP selection for load sharing purposes. o Several global addresses per interface are needed in order to seize multi-homing benefits, leading to management complexity. Observation: Multi-homing support at exit site routers and Multi- homing with router renumbering mechanisms can be used together in order to provide a more complete solution. If both mechanisms are Bagnulo, et. al. Expires December 31, 2001 [Page 8] Internet-Draft Survey on multi-homing mecanisms July 2001 used, short term failures can be managed using tunnels, while for long term failures the router renumbering mechanism is used. 2.4 Preserving active TCP sessions on Multi-homed networks. A completely different approach is introduced in "Preserving active TCP sessions on Multi-homed etworks." [6], which is based on the idea that most IPv6 interfaces will have several IP addresses assigned, specially in a multi-homed environment. When a TCP connection is established, both ends of the connection should be identified by a set of addresses, instead of only one address as it is done today. In order to do that, when a TCP connection is established, each end identifies itself with a set of valid addresses. The application to a multi-homing scenario would be as follows: Suppose that the multi- homed site has two ISP (ISPA and ISPB), and both of them have delegated an address space to the site, PrefA:Prefsite::/n and PrefB:Prefsite::/n respectively. Any host in the site that intends to use both ISPs needs al least two global addresses, PrefA:Prefsite::host and PrefB:Prefsite::host. When this host establishes a TCP connection with any other host in the Internet, it identifies itself with a set of addresses which is composed by PrefA:Prefsite::host and PrefB:Prefsite::host. If any of the ISPs crashes, the connection can survive just using the address of the other ISP. In the original approach, it is proposed that the valid set of addresses identifying a host in a TCP connection is exchanged during TCP three-way handshake, using TCP options. Afterwards, in IPng working group Tokyo meeting in 1999 [7] the usage of an IPv6 destination option was proposed. This overcomes the 40 bytes limit of TCP options. Mechanism evaluation Advantages o Provides complete fault tolerance including preservation of active TCP connections, meaning that if there is an available path, connectivity is ensured. o There is no need for changes in network devices, because it is a host-based solution. Concerns o Introduces modifications in the protocol, IP or TCP. Furthermore, in order to provide a working solution, changes are needed in both hosts involved in the connection, not only the host belonging to the multi-homed site. Bagnulo, et. al. Expires December 31, 2001 [Page 9] Internet-Draft Survey on multi-homing mecanisms July 2001 o It does not provide any tool for load sharing or ISP selection. o This mechanism could have impact on security issues, like connection hijacking, that must be considered on mechanism design. o Basic solution is limited to TCP traffic only. 2.5 Mobility mechanisms Another proposal presented in "Multihomed routing domain issues" [4] is based in the use of IP mobility mechanisms. The main idea is to use the care-of-address assignation mechanism to switch between delegated addresses in case of failure. Suppose that there is an established communication between hostA belonging to the multi-homed site and hostB, somewhere in the Internet, as shown the figure below. ___________________________________________ | Internet | | hostB | |___________________________________________| | | | | +----+ +----+ |ISPA| |ISPB| |BRA | |BRB | +----+ +----+ | | link1 | | link2 __|____________________________|___ | RA RB | | | | | | ------------------------------- | | | | | hostA | | PrefA:Prefsite:hostA | | PrefB:Prefsite:hostA | | | |___________________________________| The established connection is being routed through ISPA and PrefA:Prefsite:hostA is used. If ISPA fails, the described steps are followed in order to preserve communication: o HostA packets contain the home address destination option with PrefA:Prefsite:hostA and PrefB:Prefsite:hostA as source address, so that for every device on the path source address is Bagnulo, et. al. Expires December 31, 2001 [Page 10] Internet-Draft Survey on multi-homing mecanisms July 2001 PrefB:Prefsite:hostA and only hostB replaces this source address by PrefA:Prefsite:hostA. o HostA sends a binding update containing PrefB:Prefsite:hostA as a care-of address. Note that that authentication header is needed in this packet. o HostB sends a binding acknowledgement. This packet and all next packets are sent with PrefA:Prefsite:hostA as final destination (included in a routing header) and PrefB:Prefsite:hostA as next destination (included as destination address). Consequently, all packets are sent towards HostA using ISPB, and address "translation" is done when packets reach HostA. Mechanism Evaluation: Advantages o The mechanism provides complete fault tolerance. o It uses existing protocols. o It allows ISP selection for load sharing. Concerns o Needs Mobile IP features on destination host. o Mobile IP security mechanisms impose the use of authentication header,raising complexity. In order to use the AH, a security association is needed in both hosts, which must be established before the failure. 2.6 Routing headers usage A mechanism intended to force routing through a specific ISP in multi-homed sites is suggested in RFC 2526 [9]. The main idea is to include a routing header with an intermediate anycast address identifying selected ISP routers, in order to force the packet path through the chosen ISP. Another approach for ISP selection is site exit router selection, instead of ISP router selection. When different routers support ISP connections, exit router selection can be done using a Routing Header that includes a site-local address assigned to one of the router interfaces. In the case that more than one exit router were connected to the same ISP, this address would be Bagnulo, et. al. Expires December 31, 2001 [Page 11] Internet-Draft Survey on multi-homing mecanisms July 2001 assigned to all the connecting routers, becoming an anycast address. If the packets are routed to a single exit router, ISP selection can be implemented locally in the border device. Note that supporting both ISP connections on a single router introduces a single point of failure, which precludes the fault tolerance ability pursued in multi-homing architectures. There are some differences between the two approaches, that wiil be presented next. In the first case, the routing header was used to force a path including the ISP routers anycast address; as a consequence, processing of the routing header requires ISP routing resources. In the second case, the processing of the routing header is done by the site exit router, which presents some benefits: Improved scalability: as one ISP connects many sites with the Internet,interpretation of routing headers could be a heavy task. If it is done at site exit routers scalability is preserved. ISP independence: There is no need for ISP cooperation, such as support for the all routers anycast address in the ISP network. Mechanism evaluation Advantages o It is the only proposed method to explicit ISP selection by hosts. This enables ISP selection mechanisms based on other criteria than link availability. o This solution is based in existing protocols, so it is fast and easy to implement and deploy. o This solution is implemented completely at network level granting performance. Concerns o Overhead of routing headers. o Some host modifications are needed in order to include the appropriate routing headers. o Management of information, such as routers address could be high. 2.7 Routing support for IPv6 multi-homing A more specific multi-homing issue, related to the configuration shown in the figure below, is addressed in "Routing support for IPv6 multi-homing" [8]. Bagnulo, et. al. Expires December 31, 2001 [Page 12] Internet-Draft Survey on multi-homing mecanisms July 2001 ___________________________________________ | Internet | | | |___________________________________________| | | | | | | +----+ +----+ |TLA1| |TLA2| |BRT1| |BRT2| +----+ +----+ | | link1 | TLA1::/16 link2 | TLA2::/16 | | +----+ +----+ |NLA1| |NLA2| |BRN1| |BRN2| +----+ +----+ | | link3 | TLA1:NLA1::/16+n1 link4| TLA2:NLA2::/16+n2 __|____________________________|___ | RA RB | | | | Multi-homed site | |T1:N1:Prefsite::/16+n1+n | |T2:N2:Prefsite::/16+n2+n | |___________________________________| In the above configuration, the multi-homed site is connected to two ISPs. Each one of the connecting ISP belongs to a different TLA (TLA1 and TLA2). Each ISP delegates a site prefix: T1:N1:Prefsite::/16+n1+n and T2:N2:Prefsite::/16+n2+n. Routing information is propagated as described in figure 5, so TLA1 border router (BRT1) propagates TLA1::/16 to NLA1 through link1, TLA2 border router (BRT2) propagates TLA2::/16 to NLA2 through link2, NLA1 border router (BRN1) propagates TLA1:NLA1::/16+n1 to the site through link3, NLA2 border router (BRN2) propagates TLA2:NLA2:/16+n2 to the site through link4. Suppose that link1 fails. This has no relevant impact in inbound traffic, because after trying without success with T1:N1:Prefsite::host address, external hosts will try with T2:N2:Prefsite::host and connection will be established. The main problem appears when an internal host initiates a connection with an external host. If the internal host uses T1:N1:Prefsite::host as source address, returning packets of this connection have no available inbound path. In order to avoid the presented behaviour, the idea is to propagate TLA reachability information besides NLA reachability information through link3 and link4. In this case and Bagnulo, et. al. Expires December 31, 2001 [Page 13] Internet-Draft Survey on multi-homing mecanisms July 2001 in normal conditions, NLA1 border router (BRN1) propagates TLA1:NLA1::/16+n1 and TLA1::/16 to the site through link3, NLA2 border router (BRN2) propagates TLA2:NLA2:/16+n2 and TLA2::/16 to the site through link4. If link1 fails, NLA1 border router (BRN1) only propagates TLA1:NLA1::/16+n1 to the site through link3, so internal routers know that the Internet is not reachable through NLA1. This information can be used by the source address selection algorithm of the internal host to avoid the usage of those addresses as source address. Bagnulo, et. al. Expires December 31, 2001 [Page 14] Internet-Draft Survey on multi-homing mecanisms July 2001 3. Security considerations There are no specific security issues introduced by this document. For the specific security issues about the mechanisms descibed the reader is referred to the referenced documents. Bagnulo, et. al. Expires December 31, 2001 [Page 15] Internet-Draft Survey on multi-homing mecanisms July 2001 References [1] Jieyun, J., "IPv6 multi-homing with route aggregation", Internet draft draft-ietf-ipng-ipv6multihome-with-aggr-00.txt, November 1999. [2] Bates, T., "Scalable support for multi-homed multi-provider connectivity", January 1998. [3] Hagino, J., "IPv6 multi-homing support at site exit routers", April 2001. [4] Dupont, F., "Multihomed routing domain issues", Internet draft draft-ietf-ipngwg-multi-isp-00, September 1999. [5] Crawford, M., "Router Renumbering for IPv6", August 2000. [6] Tattam, P., "Preserving active TCP sessions on Multi-homed networks", September 1999. [7] Hinden, R. and S. Deering, "IPng working group minutes/Tokyo meeting", September 1999. [8] Bragg, N., "Routing support for IPv6 multi-homing", November 2000. [9] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", March 1999. 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 Bagnulo, et. al. Expires December 31, 2001 [Page 16] Internet-Draft Survey on multi-homing mecanisms July 2001 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 Arturo Azcorra Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 EMail: azcorra@it.uc3m.es URI: http://www.it.uc3m.es David Larrabeiti Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 EMail: dlarra@it.uc3m.es URI: http://www.it.uc3m.es Bagnulo, et. al. Expires December 31, 2001 [Page 17] Internet-Draft Survey on multi-homing mecanisms July 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). 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 assigns. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Bagnulo, et. al. Expires December 31, 2001 [Page 18]