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.

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.

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:

• 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.
• Load sharing among available connections, so that both inbound and outbound traffic is balanced using the existing providers.
• Simple management.

• The site propagates PrefA:Prefsite::/n to ISPA and ISPB through link3 and link4 respectively.
• ISPB propagates PrefA:Prefsite::/n to ISPA through link5. Note that ISPB does NOT propagates routing information about PrefA:Prefsite::/n to the Internet.
• ISPA propagates PrefA::/nA to the Internet through link1.

• 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.
• 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).

• Neither new protocol nor new mechanism are needed, facilitating deployment.
• Several global addresses per interface are no longer needed to obtain the benefits of the multi-homing architecture, which simplifies management on the site.
• Provides fault tolerance if one of the links (link3 or link4) connecting to the ISP fails.
• Preserves established TCP connections through link failure.
• Allows load sharing, provided that local policies are capable to define which exit link to use.

• 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 use for inbound traffic.
• The tasks that the primary ISP must complete imply a more complex ISP administration.
• 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.
• 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.
• 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.
• 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.

• Provides fault tolerance for ISP connecting link failure.
• Preserves established TCP connections through link failure.
• There is no need for new protocols or mechanisms.

• Does not provide fault tolerance in case of ISP failure.
• Does not provide tools for ISP selection for load sharing.
• 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.
• 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

• Provides stable configuration in case of long term ISP failure. Note that it provides ISP fault tolerance, not only link fault tolerance.
• There is no need for any new protocol or mechanism.

• It does not preserve established TCP connections.
• It does not provide tools for ISP selection for load sharing purposes.
• Several global addresses per interface are needed in order to seize multi-homing benefits, leading to management complexity.

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

• Provides complete fault tolerance including preservation of active TCP connections, meaning that if there is an available path, connectivity is ensured.
• There is no need for changes in network devices, because it is a host-based solution.

• 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.
• It does not provide any tool for load sharing or ISP selection.
• This mechanism could have impact on security issues, like connection hijacking, that must be considered on mechanism design.
• Basic solution is limited to TCP traffic only.

2.5 Mobility mechanisms

• 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 PrefB:Prefsite:hostA and only hostB replaces this source address by PrefA:Prefsite:hostA.
• HostA sends a binding update containing PrefB:Prefsite:hostA as a care-of address. Note that that authentication header is needed in this packet.
• 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.

• The mechanism provides complete fault tolerance.
• It uses existing protocols.
• It allows ISP selection for load sharing.

• Needs Mobile IP features on destination host.
• 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 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

• It is the only proposed method to explicit ISP selection by hosts. This enables ISP selection mechanisms based on other criteria than link availability.
• This solution is based in existing protocols, so it is fast and easy to implement and deploy.
• This solution is implemented completely at network level granting performance.

• Overhead of routing headers.
• Some host modifications are needed in order to include the appropriate routing headers.
• Management of information, such as routers address could be high.

2.7 Routing support for IPv6 multi-homing

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.

References

Authors' Addresses

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.