[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Survey on proposed IPv6 multi-homing mechanisms
Hi,
We have been working on a survey of proposals related to IPv6 multi-homing.
We think that this could be a good input for a discussion about
which of these ideas can be valuable, and need to be further developed.
We have included all the mechanisms that we have found. If there are other
mechanisms, please let us know. We have also includes some advantages and
concerns about the mechanisms, but we think that discusion will really
disclose much more points.
After our study, we feel that could be interesting to develop solution
presented as "Preserving active TCP sessions on multi-homed IPv6 networks",
what do you feel about it?
We hope you enjoy it,
m
M. Bagnulo
A. Garcia-Martinez
A. Azcorra
D. Larrabeiti
Universidad Carlos III de Madrid
Survey on proposed IPv6 multi-homing network level mechanisms
Introduction
This article presents proposed solutions and tools related to
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.
Index
1. IPv6 multi-homing with route aggregation.........................1
2. IPv6 multi-homing support at site exit routers...................3
3. Multi-homing with router renumbering.............................4
4. Preserving active TCP sessions on Multi-homed networks...........6
5. Mobility mechanisms..............................................7
6. Routing headers usage............................................8
7. Routing support for IPv6 multi-homing............................9
1. IPv6 multi-homing with route aggregation.
The solution presented in [YU] 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.
Solution mechanism:
______________________________
| Internet |
|______________________________|
| |
link1 | link5 | link2
ISPA--------------------- ISPB
\ /
link3 \______________________/ link4
| Multi-homed site |
| PrefA:Prefsite::/n |
|______________________|
Figure 1: Multi-homing with route aggregation
Survey on multi-homing mecanisms 2
In the topology depicted in Figure 1, 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:
- 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.
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:
- 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).
Mechanism evaluation
Advantages
- 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.
Concerns
- 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
Survey on multi-homing mecanisms 3
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. IPv6 multi-homing support at site exit routers.
This mechanism is originally presented in [BATES] and further detail is
given in [ITOJUN]. 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. [ITOJUN] 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:
+----+ +----+
|ISPA|____________________ |ISPB|
|BRA | __________________\___|BRB |
+----+ / \ +----+
| /link3 link4 \ |
link1 | / \ | link2
_|_/_________________________\__|_
| RA RB |
| Multi-homed site |
|PrefA:Prefsite PrefB:Prefsite|
|__________________________________|
Figure 2: Multi-homing support at exit site routers
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
Survey on multi-homing mecanisms 4
advertised so secondary links become a valid option for the routers.
Mechanism evaluation
Advantages
- Provides fault tolerance for ISP connecting link failure.
- Preserves established TCP connections through link failure.
- There is no need for new protocols or mechanisms.
Concerns
- 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.
3. Multi-homing with router renumbering
This proposal is described in [DUPONT]. It basically consists of the
usage of Router Renumbering [CRAWFORD] 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|
|__________________________________|
Figure 3: Multi-homing with router renumbering
Survey on multi-homing mecanisms 5
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 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
- 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.
Concerns
- 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.
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 used, short
term failures can be managed using tunnels, while for long term failures
the router renumbering mechanism is used.
Survey on multi-homing mecanisms 6
4. Preserving active TCP sessions on Multi-homed networks.
A completely different approach is introduced in [TATTAM], 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.
Originally, in [TATTAM], 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 [TOKYO] 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
Concerns
- 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
5. Mobility mechanisms
Another proposal presented in [DUPNOT] 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
Survey on multi-homing mecanisms 7
hostA belonging to the multi-homed site and hostB, somewhere in the
Internet, as shown in figure 4.
___________________________________________
| Internet |
| hostB |
|___________________________________________|
| |
| |
+----+ +----+
|ISPA| |ISPB|
|BRA | |BRB |
+----+ +----+
| |
link1 | | link2
__|____________________________|___
| RA RB |
| | | |
| ------------------------------- |
| | |
| hostA |
| PrefA:Prefsite:hostA |
| PrefB:Prefsite:hostA |
| |
|___________________________________|
Figure 4: Mobility mechanisms
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:
- 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.
Mechanism Evaluation:
Advantages:
- The mechanism provides complete fault tolerance.
- It uses existing protocols.
- It allows ISP selection for load sharing.
Survey on multi-homing mecanisms 8
Concerns
- Needs Mobile IP implementation on destination host. So, modifications
in external hosts are needed to achieve internal multi-homing.
- Mobile IP security mechanisms impose the use of authentication header,
raising complexity.
6. Routing headers usage
A mechanism intended to force routing through a specific ISP in
multi-homed sites is suggested in [JOHNSON]. 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.
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.
Concerns.
- 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.
Survey on multi-homing mecanisms 9
7. Routing support for IPv6 multi-homing
A more specific multi-homing issue, related to the configuration shown
in figure 4, is addressed in [BRAGG].
___________________________________________
| 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 |
|___________________________________|
Figure 5: Routing support for multi-homing
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
Survey on multi-homing mecanisms 10
idea is to propagate TLA reachability information besides NLA
reachability information through link3 and link4. In this case and 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.
References
[YU]J. Yu, "IPv6 multi-homing with route aggregation",
draft-ietf-ipng-ipv6multihome-with-aggr-00.txt, 11/1999
[BATES] T. Bates, "Scalable support for multi-homed multi-provider
connectivity", RFC2260, 1/1998
[ITOJUN]Jun-ichiro Hagino, "IPv6 multi-homing support at site exit
routers", draft-ietf-ipngwg-ipv6-2260-01.txt, 4/2001
[DUPONT] F. Dupont, "Multihomed routing domain issues",
draft-ietf-ipngwg-multi-isp-00,txt, 9/1999
[CRAWFORD] M. Crawford, "Router Renumbering for IPv6", RFC 2894, 8/2000
[TATTAM] P. Tattam, "Preserving active TCP sessions on Multi-homed
networks", 9/1999
[TOKYO] IPng working group minutes/Tokyo meeting, 1999
[BRAGG] N. Bragg, "Routing support for IPv6 multi-homing",
draft-bragg-ipv6-multihoming-00.txt, 11/2000
[JOHNSON] Johnson, D., Deering, S.: RFC 2526 - Reserved IPv6 Subnet
Anycast Addresses. March 1999.
Authorīs addrsses.
Marcelo Bagnulo
Departamento de Ingenieria Telematica
Universidad Carlos III de Madrid
Av. Universidad 30 - 28911
LEGANES (MADRID) SPAIN
Email: marcelo@it.uc3m.es
Alberto Garcia-Martinez
Departamento de Ingenieria Telematica
Universidad Carlos III de Madrid
Av. Universidad 30 - 28911
LEGANES (MADRID) SPAIN
Email: alberto@it.uc3m.es
Arturo Azcorra
Departamento de Ingenieria Telematica
Universidad Carlos III de Madrid
Av. Universidad 30 - 28911
LEGANES (MADRID) SPAIN
Email: azcorra@it.uc3m.es
Survey on multi-homing mecanisms 11
David Larrabeiti
Departamento de Ingenieria Telematica
Universidad Carlos III de Madrid
Av. Universidad 30 - 28911
LEGANES (MADRID) SPAIN
Email: dlarra@it.uc3m.es