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]