Subject: Survey on proposed IPv6 multi-homing mechanisms

From: "marcelo" <[email-masked]>
Date: Mon, 25 Jun 2001 22:48:36 +0200

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: [email-masked]

Alberto Garcia-Martinez
Departamento de Ingenieria Telematica
Universidad Carlos III de Madrid
Av. Universidad 30 - 28911
LEGANES (MADRID) SPAIN
Email: [email-masked]

Arturo Azcorra
Departamento de Ingenieria Telematica
Universidad Carlos III de Madrid
Av. Universidad 30 - 28911
LEGANES (MADRID) SPAIN
Email: [email-masked]

                  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: [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Mon, 25 Jun 2001 21:16:47 -0700

i hope you plan to produce this as an internet draft

randy

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 26 Jun 2001 15:55:02 +0200

Hi Marcelo,

[cross-posting to mobile-ip list]

> disclose much more points.
[...]
> Internet, as shown in figure 4.

Currently, Mobile IP WG has to come up with a solution to establish
security associations between the MN (host A) and the CN (host B). SA
establishment using public key infrastructure is assumed to not be
available everywhere and with all CNs.

The (unofficially?) proposed draft-perkins-bake-00.txt suggests a (weak
but strong enough for the purpose) mechanism that involves a home agent
during the key exchange. The validity of the MN's binding of the home
address is verified by the CN by sending packets via the home network.
The home agent address belongs to the same prefix as the MN's home
address, i.e. PrefA:Prefsite::.

If no SA is set up prior to the failure of ISPA, the key exchange will
fail since the CN can't send packets through the home agent any more.

/Mattias

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Jun 2001 17:08:36 +0200

In your previous mail you wrote:

=> please keep further messages in the multi6 list.

   
=> the mobility mechanism for IPv6 multi-homing was proposed before
the security details were specified in the IPv6 mobility drafts...
So don't expect that it works with any suggestion of this year (:-).
More seriously, the idea was that if the mechanism is applied to
critical connections then these connections are already protected
by some mechanisms, i.e. the key material is already available or
very easy to setup.

   
=> a SA set up prior to the failure of ISPA is the very easy case but
can be common. Issues with the lack of home agent are different:
 - the CN should not flush the binding (i.e. a bit/sub-option/...
   is needed, its meaning should be "keep this binding as long as possible")
 - there is no support for mobile to mobile, in the multi-home environment
   this is translated by no support for failure on both the node and
   its CN ISPs or one has to assume that this condition is detectable.
   A common case is the failure of a high level ISP: if both nodes
   are connected to it they will see a failure at the same time,
   to understand this situation is hard but not impossible...
I like this mechanism (of course :-) but we wait for the IPv6 mobility RFC
before work again on it. BTW this is very easy to implement (movement
detection is a dream).

Regards

[email-masked]

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 26 Jun 2001 23:47:19 +0200

> => please keep further messages in the multi6 list.

Ok.

> So don't expect that it works with any suggestion of this year (:-).

I know, just wanted to point out a realization problem.

> by some mechanisms, i.e. the key material is already available or

Sounds highly visionary to me. Maybe it can be so.

>    to understand this situation is hard but not impossible...

  - Global PKI...?

> before work again on it. BTW this is very easy to implement (movement

I agree that mobility has powerful mechanisms to overcome "small"
problems such as multihoming... ;)

Still some work has to be done because this won't work out of the box.

/Mattias