Internet DRAFT - draft-kuntz-nemo-multihoming-test
draft-kuntz-nemo-multihoming-test
NEMO Working Group R. Kuntz
Internet-Draft M. Tsukada
Expires: January 19, 2006 WIDE at Keio University
E. Paik
KT
T. Ernst
K. Mitsuya
WIDE at Keio University
July 18, 2005
Evaluating Multiple Mobile Routers and Multiple NEMO-Prefixes in NEMO
Basic Support
draft-kuntz-nemo-multihoming-test-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 January 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes the tests performed and results obtained with
multihomed mobile networks managed by NEMO Basic Support. We have
Kuntz, et al. Expires January 19, 2006 [Page 1]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
particularly analyzed mobile networks with multiple mobile routers
and mobile networks with multiple NEMO-Prefixes.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Testing Environment . . . . . . . . . . . . . . . . . . . . . 4
3. Case (1,1,1): Single MR, Single HA, Single Prefix . . . . . . 5
3.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1 Using interface preferences . . . . . . . . . . . . . 6
3.2.2 Using Multiple Care-of Addresses registration . . . . 6
3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Case (1,1,2): Single MR, Single HA, Multiple NEMO-Prefixes . . 7
4.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1 Using interface preferences . . . . . . . . . . . . . 7
4.2.2 Using Multiple Care-of Addresses registration . . . . 8
4.3 Potential problems and solutions . . . . . . . . . . . . . 8
5. Case (1,2,1): Single MR, Multiple HAs, Single NEMO-Prefix . . 8
5.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3 Potential problems and solutions . . . . . . . . . . . . . 9
6. Case (1,2,2): Single MR, Multiple HAs, Multiple
NEMO-Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3 Potential problems and solutions . . . . . . . . . . . . . 11
7. Case (2,1,1): Multiple MRs, Single HA, Single NEMO-Prefix . . 11
7.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2.1 With both MRs in a foreign network . . . . . . . . . . 13
7.2.2 With MR2 at home and MR1 in a foreign network . . . . 14
7.3 Potential problems and solutions . . . . . . . . . . . . . 15
8. Case (2,1,2): Multiple MRs, Single HA, Multiple
NEMO-Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2.1 With both MRs in a foreign network . . . . . . . . . . 17
8.2.2 With MR2 at home and MR1 in a foreign network . . . . 18
8.3 Potential problems and solutions . . . . . . . . . . . . . 18
Kuntz, et al. Expires January 19, 2006 [Page 2]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
9. Case (2,2,1): Multiple MRs, Multiple HAs, Single
NEMO-Prefix . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.3 Potential problems and solutions . . . . . . . . . . . . . 20
10. Case (2,2,2): Multiple MRs, Multiple HAs, Multiple
NEMO-Prefixes . . . . . . . . . . . . . . . . . . . . . . . 21
10.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.3 Potential problems and solutions . . . . . . . . . . . . . 21
11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 22
12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1 Changes from version 01 to 02 . . . . . . . . . . . . . . 22
12.2 Changes from version 00 to 01 . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 26
Kuntz, et al. Expires January 19, 2006 [Page 3]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
1. Introduction
In this document we study the support of multihoming in the NEMO [12]
context. We present the results of tests performed on NEMO Basic
support [8] with multihoming configurations. We discuss the
potential problems that may prevent to combine multihoming with NEMO
Basic Support. We also make some recommendations to solve issues in
case of mobile router failures.
Our tests follow the spirit of the analysis of multihoming in NEMO
described in [3] [19]. The terminology used is this memo is defined
in [9] and [2] whereas the multihomed configurations are classified
according to the taxonomy defined in [3].
We first give a short description of our testbed and implementations
used before describing our tests on distinct configurations,
following the same order of the classification defined in [3]. Some
configurations remain to be tested.
2. Testing Environment
The multihoming tests were performed on the indoor testbed of the
Nautilus6 Project [10]. The indoor testbed allows us to test
protocols under development. It is composed of two mobile routers
and two home agents, each running NEMO Basic Support on NetBSD 1.6.2
or Debian GNU/Linux with kernel 2.6.8.1. Several LFNs are located in
each mobile network. Additionaly, the mobile routers can
periodically change their point of attachment to the Internet thanks
to an emulator that allows to switch between the mobile router's home
network and four foreign networks.
At the moment, three NEMO Basic Support implementations are freely
available:
o SHISA [15] is an implementation for *BSD Operating Systems of
Mobile IPv6 and NEMO Basic Support developed in WIDE project [14].
SHISA supports mobile node, home agent, correspondent node and
DHAAD, and also various extensions such as NEMO Basic Support [8]
(in implicit and explicit mode) and multiple care-of addresses
registration [4].
o NEPL (NEMO Platform for Linux) [16] is a NEMO implementation for
Linux based on MIPL2 [17]. It has been developed by Go-Core
project at the Helsinki University of Technology [17] in
cooperation with Nautilus6 [10]. It aims to be RFC3963 [8]
compliant, it supports both implicit and explicit mode signaling,
and DHAAD.
Kuntz, et al. Expires January 19, 2006 [Page 4]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
o ATLANTIS [13] is an implementation of NEMO Basic Support based on
draft-03 of NEMO Basic Support [8]. Developed by Nautilus6, it is
presented as an extension of KAME MIPv6 implementation [11] for
NetBSD 1.6.1. It supports MR and HA functionalities and both
explicit and implicit modes. The HA supports both modes at once
and the MR switches their mode by configuration. It also supports
DHAAD and IPSec protection between HA and MR.
Please note that each of these implementations are still work in
progress.
In the tests presented in this document, we used both SHISA and NEPL.
Those implementations are currently under progress. However we
confirm that communication between MRs works well. Nested mobility
is also working: first nested level of VMN and VMR can communicate
with other internet nodes. We also have successfully tested
interoperability between those implementations [18]. The case
(1,1,1) presented below describes a little bit further each
implementation capabilities.
3. Case (1,1,1): Single MR, Single HA, Single Prefix
We are interested in multihomed mobile networks advertising multiple
NEMO-prefixes, but this case is a good scenario to test each
implementation capabilities.
3.1 Scenario
_
CN|_|---| _ _____
|-|_|-| |
_ | |
_ | p1 __ |-|_|-| |-|
|_|-| <- | |-CoA1--| | | | _ |-
|------| | | | |-|_|-|
| |__|-CoA2--| _ | | |
|-|_|-|_____|
LFN MR ARs Internet HA Home Network
(1,1,1) Simple Mobile Network
The MR has two egress interfaces and advertises one NEMO-Prefix on
its ingress interface to the mobile network. The MR has only one
home address and can either use an interface preference mechanism to
bind either CoA1 or CoA2 to this HoA at the home agent, or use
Kuntz, et al. Expires January 19, 2006 [Page 5]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
multiple care-of addresses (MCoA) registration [4] to bind both
care-of addresses to its home address at the home agent. The HA acts
as the default gateway on the home link.
3.2 Results
3.2.1 Using interface preferences
The MR uses only one egress interface at the same time. We can put a
preference on each interface. The mobile router uses the available
interface which has the highest preference, and binds its care-of
address to its home address at the home agent. If the running
interface fails, then another interface can be automatically chosen
and the binding updated at the home agent, transparently for all the
communications coming from or going through the MR.
In this test, both egress interfaces are connected to a foreign
network. If the mobile router supports interface preferences
mechanism, then it can recover when the active interface fails by
using the other interface. The mobile router sends a binding update
via the newly activated interface to bind its new CoA to the MR's HoA
at the home agent. Both HA and MR updates the tunnel endpoints, the
interface change is done transparently for both the MR and LFN's
communications.
3.2.2 Using Multiple Care-of Addresses registration
With MCoA registration [4], the MR can bind each interface's CoA to
the same HoA at the home agent. A binding identifier (BID) is
defined for each CoA, the MR can then send each flow (defined by
policies such as protocol, ports, destination address etc.) to one
specific interface according to its BID. With MCoA registration, the
MR can get benefit from multiple paths to the Internet, such as load
sharing, load balancing, and failure recovery.
In this test, both egress interfaces are connected to a foreign
network. If both the mobile router and its home agent support MCoA
registration, then the mobile network can recover from an interface
failure on the MR: if the mobile router and the home agent can
dynamically adapt the flow policies, the other active interface can
be used to send all the flows that were sent to the failed interface.
3.3 Conclusion
On a multihomed mobile router, interface preference mechanisms or
multiple care-of addresses registration can be used to recover from
an interface failure. MCoA registration allows to get full benefits
of the multiple paths to the Internet.
Kuntz, et al. Expires January 19, 2006 [Page 6]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
At the moment, only SHISA on BSD operating systems implements
interface preferences mechanisms and MCoA registration. Those
features are still under development on NEPL for Linux operating
system. As all (1,*,*) tests require at least interface preference
mechanisms, only SHISA will be used for (1,*,*) tests, but both SHISA
and NEPL will be used for (2,*,*) tests.
4. Case (1,1,2): Single MR, Single HA, Multiple NEMO-Prefixes
4.1 Scenario
_
CN|_|---| _ _____
|-|_|-| |
_ | |
_ | p1 __ |-|_|-| |-|
|_|-| <- | |-CoA1--| | | | _ |-
|------| | | | |-|_|-|
| <- |__|-CoA2--| _ | | |
p2 |-|_|-|_____|
LFN MR ARs Internet HA Home Network
(1,1,2) Multihomed Mobile Network
The MR has two egress interfaces and advertises two different NEMO-
Prefixes on its ingress interface(s) to the mobile network. The MR
has only one home address. In this test, we can expect to register
both NEMO-prefixes for one care-of address at a time (using interface
preferences) at the home agent, or, if we use MCoA registration, to
register both NEMO-Prefixes for both care-of addresses at the same
time at the home agent. The HA acts as the default gateway on the
home link.
4.2 Results
4.2.1 Using interface preferences
The MR uses only one egress interface at the same time and registers
the CoA it uses at the home agent. Both MNPs are registered with a
single BU for one CoA.
As for the (1,1,1) case, the MR can recover if the active interface
fails by using the other interface. In that case the MR sends a BU
with both MNPs to bind the CoA of the newly activated interface to
the MR's HoA at the home agent.
Kuntz, et al. Expires January 19, 2006 [Page 7]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
Two MNPs are advertised inside the mobile network. The LFNs can
configure two IPv6 addresses from these prefixes, and are reachable
via both addresses. The mobile router only use one interface as the
same time, and binds both MNPs to the same care-of address. Thus, as
long as one egress interface is usable on the MR, all LFNs are
reachable at both addresses.
4.2.2 Using Multiple Care-of Addresses registration
The MR binds each interface's CoA to the same HoA at the home agent
thanks to MCoA registration.
In this test, we have defined some simple policies as followed: the
mobile router sends all traffic with source address built from MNP p1
to one interface, and all traffic with source address built from MNP
p2 to the other interface. We have defined the same policies on the
home agent for the destination address of the packets. In that case
each class of traffic uses a different MR-HA tunnel. If one of the
MR's egress interface fails, the mobile router and the home agent
need to dynamically adapt the policies to redirect some traffic from
the failed interface to the other active one.
4.3 Potential problems and solutions
If we bind more than one care-of address to the same home address at
the home agent (with MCoA registration), we need to select which path
to use for each flow. This can be done with policies defined by the
user of the mobile router, or using profile management as described
in [20].
If one of the MR's egress interface fails, the MR and the HA must be
able to dynamically adapt its routing policies to redirect all the
traffic from the failed interface to another active one.
Two MNPs are advertised on the mobile network. The LFNs can
configure two addresses and have to choose one of them when they
initiate a communication with a correspondent. No ingress filtering
issues should happen if the MR and the HA are properly configured to
route the traffic from both MNPs.
5. Case (1,2,1): Single MR, Multiple HAs, Single NEMO-Prefix
Kuntz, et al. Expires January 19, 2006 [Page 8]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
5.1 Scenario
_
CN|_|---| _ _____
|-|_|-| |
_ | |
_ | p1 __ |-|_|-| |-| _
|_|-| <- | |-CoA1--| | | | _ |-|1|
|------| | | | |-|_|-| _
| |__|-CoA2--| _ | | |-|2|
|-|_|-|_____|
LFN MR ARs Internet AR Home Network with 2 HAs
(1,2,1) Multihomed Mobile Network
The MR has two egress interfaces and advertises one NEMO-Prefix on
its ingress interface to the mobile network. Registering the same
MNP to two different home agents raises an issue: each HA has to
advertise a route to the MNP, which is a problem if each HA is in a
different domain. In this test we configure both HAs on the same
home link. They do not act as a gateway to the Internet. We can
have several scenario:
o The MR has two home addresses, and registers each one on a
different home agent, with the same MNP.
o The MR has one HoA, two CoAs (but only registers one at the same
time), registers the same HoA/CoA to each HA, and use the
interface preference mechanism.
o The MR has one HoA, two CoAs and registers HoA/CoA1/CoA2 to each
home agent (thanks to MCoA registration).
5.2 Results
At the moment the MR cannot register to multiple home agents that are
on the same home link. Thus we cannot test any of the scenario
described previously. This will be for a later session, when
implementation will allow that.
5.3 Potential problems and solutions
We can at least raise the following issues that may happen in such
case. In the case of multiple home addresses, how the mobile router
Kuntz, et al. Expires January 19, 2006 [Page 9]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
would choose it when initiating communications? This problem would
be the same on a host operating Mobile IPv6 and is also discussed in
[7]. Also, as only one MNP is registered by the MR on two different
home agents, two different routes to the MNP are available, via two
home agents.
However the benefits we can get from such topology are interesting:
o Home agent redundancy. If one HA fails, the other one can relay
the failed one. We can also use bicasting via both HAs.
o Tunnel redundancy. If one of the MR's interface loses its
connectivity, the other one could be used transparently for the
ongoing communications.
6. Case (1,2,2): Single MR, Multiple HAs, Multiple NEMO-Prefixes
6.1 Scenario
_ | _
CN|_|---| _ _____ |-|1|-|
|-|_|-| |-| |-
_ | |
_ | p1 __ |-|_|-| |-|
|_|-| <- | |-CoA1--| | | | _ |-
|------| | | | |-|2|-|
| <- |__|-CoA2--| _ | | |
p2 |-|_|-|_____|
LFN MR ARs Internet HAs Home Network
(1,2,2) Multihomed Mobile Network
The MR has two egress interfaces and advertises two NEMO-Prefixes on
its ingress interface(s) to the mobile network. Each home agent are
in in a different network. Both MRs' interfaces are in a foreign
network. The MR has two home addresses and registers one HoA and one
MNP per home agent. The LFNs can configure two IPv6 addresses, one
from each MNP advertised in the mobile network. Each HA acts as the
default gateway on its home link.
6.2 Results
Each MR's egress interface has one HoA/CoA/MNP registered to one HA.
If one of the MR's egress interface fails, both the MR and LFNs are
Kuntz, et al. Expires January 19, 2006 [Page 10]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
not reachable anymore to the address built from the prefix that is
related to this interface. If the MR does not redirect the flow from
the failed egress interface to the other one, the LFNs'
communications are broken and LFNs cannot reach the Internet anymore
if they use the address built from the prefix associated to the
failed interface as source address.
6.3 Potential problems and solutions
Two MNPs are advertised in the mobile network, thus LFNs can be
multihomed. All packets go through one MR, so ingress filtering
should not happen on the MR side. If the MR always sends the packets
to the home agent which is related to the prefix that the source
address is built from, no ingress filtering should happen on the HA
side.
However, in case of failures and to keep transparency for the LFNs,
The MR could redirect the packets to another active interface. In
such a case, ingress filtering can occur at the home agent, which may
drop packets with a source address different from what it is allowed
to receive from the MR. Also, redirecting the packets from one
interface to another would only recover one way of the
communications, as the other way would still take the path via the
failed interface. The MR could then move the tunnel endpoint from
the failed interface to the active one: the active interface would
have to manage two home addresses, and two tunnels to two different
home agents.
In case of MR's interface failure, the LFN may have to change the
source address it uses to send its datas. If so, all ongoing
communications would be reset as TCP connections cannot survive to IP
address change.
7. Case (2,1,1): Multiple MRs, Single HA, Single NEMO-Prefix
7.1 Scenario
We will first test with both MRs in foreign networks:
Kuntz, et al. Expires January 19, 2006 [Page 11]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
_
CN|_|---| _ _____
|-|_|-| |
_ | |
| <-p1 ___ |-|_|-| |-|
_ |------|_1_|-CoA1--| | | | _ |-
|_|-| ___ | | |-|_|-|
|------|_2_|-CoA2--| _ | | |
<-p1 |-|_|-|_____|
LFN MRs ARs Internet HA Home Network
(2,1,1) Multihomed Mobile Network
both MRs in foreign networks
Each MR (MR1 and MR2) has one egress interface and advertises the
same NEMO-Prefix p1 on the mobile network. When the HA receives a BU
with a MNP that is already in binding cache from another MR, it
creates a new entry in the binding cache. The home agent thus has
two binding cache entries: one for HoA1/CoA1/p1, and one for HoA2/
CoA2/p1. The HA acts as the default gateway on the home link.
Notes:
o The LFN's default router can be either MR1 or MR2.
o The HA can forward packets to the MNP via either MR1 or MR2.
o In the implementations we use (on Linux and on BSD), in the case
several MRs register the same MNP to the home agent, the home
agent always selects the first MR that registered to forward
packet to the MNP.
o The LFN's routers list contains both MRs. Once its default router
is selected, the LFN will then always use it unless its default
router is not reachable anymore.
We will then test with one MR in a foreign network, and the second MR
at home. The mobile router that is at home does not register to its
home agent:
Kuntz, et al. Expires January 19, 2006 [Page 12]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
_
CN|_|---| _ _____
|-|_|-| |
_ | |
| <-p1 ___ |-|_|-| |-|
_ |------|_1_|-CoA1--| |_____| | _ |
|_|-| ___ |-|_|-|
|------|_2_|---------------------------|
<-p1
LFN MRs ARs Internet HA Home Network
(2,1,1) Multihomed Mobile Network
MR2 at home, MR1 in foreign network
Notes:
o The LFN's default router can be either MR1 or MR2.
o The HA can forward packets to MNP via either MR1 or MR2.
7.2 Results
7.2.1 With both MRs in a foreign network
The LFN's default router is MR1 and HA forwards packets to the mobile
network via MR1.
If MR1's egress interface fails, the home agent is able to route
packets to the MNP via MR2. Once the binding cache entry and the
routes relative to MR1 are deleted on the home agent, it is able to
choose the other MR to reach the mobile network. If the
implementation or the operating system cannot handle multiple routes
to the same MNP, the HA may have to wait to receive a BU from MR2 to
build a new route to the MNP. As the LFN still uses MR1 as default
router, it cannot reach the Internet. In our case we configured MR1
to start sending router advertisements with a lifetime set to 0, to
force the LFN to choose another default router.
If MR1's ingress fails, the LFN is able to change its default router,
but the home agent may still use the failed MR as entry point of the
mobile network.
If we shutdown MR1, or if both ingress and egress interfaces fails,
the HA chooses MR2 to forward packets to the mobile network (once the
Kuntz, et al. Expires January 19, 2006 [Page 13]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
binding cache entry and the routes relative to MR1 have been deleted)
and the LFNs choose MR2 as default router. In this scenario, we can
get a stable configuration without any manual operations.
If LFN's default router is MR1 and HA forwards packets to the mobile
network via MR2, the path for the communication between a CN and a
LFN is asymmetrical, but it does not bring any new issues to the
previous cases.
7.2.2 With MR2 at home and MR1 in a foreign network
We have first tested with a static route installed on the HA to the
MNP via the MR that is at home. According to the implementation, the
static route is preferred to the route installed by the mobility
daemon via the MR that is in foreign network, or the contrary. This
can raise several issues: if the static route is preferred, then if
the MR that is at home fails, the MR in foreign network will never be
used by the home agent as an entry point to the mobile network,
unless we manually delete the static route on the home agent. If the
route installed by the mobility daemon is preferred, then the mobile
router that is at home will never be used as an entry point to the
mobile network.
We then have tested using a routing protocol (RIPNG using the ZEBRA
routing software) between the MR that is at home and the home agent.
In that case, on both operating systems, the home agent prefers a
route installed by the mobility daemon rather than a route installed
by ZEBRA from RIPNG announces. Then, the mobile router that is in
foreign network is always used as an entry point to the mobile
network by the home agent. However, if that MR fails, the route
installed from RIPNG announces is used and the mobile network can
still be reachable by correspondents.
We then modified ZEBRA in order that the home agent prefers a route
installed from RIPNG announces rather than from the mobility daemon.
In that case, all the traffic to the mobile network is sent through
the MR that is in its home network. If this MR fails, it takes some
time before the HA uses the route installed by the mobility daemon:
with RIPNG, routes are considered as expired once 180 seconds elapse
from the last time the timeout was initialized. Then the route entry
is still present in the routing table during 120 seconds with a
metric set to 16 (infinity).
On the LFN side, it could be useful that it chooses the MR that is at
home as default router. The MR in foreign network could advertise RA
with a lifetime set to 0 or use ICMP redirects as long as the other
MR is at home and alive. This would need some cooperation protocol
between MRs.
Kuntz, et al. Expires January 19, 2006 [Page 14]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
7.3 Potential problems and solutions
Regarding to these tests, we can discuss about:
o A mechanism for the LFN to change quickly its default router in
case of egress interface failure on it.
o A mechanism for the LFN to change its default router to keep a
symmetric path between CNs and LFNs. It means that when one of
the MR fails, LFN must be able to switch to the MR that will be
chosen by the home agent to forward packets to the mobile network.
It requires a mechanism between HA and MR and between MR and LFN.
o A mechanism for the MR to deregister quickly towards its home
agent when the MR notices a failure. For example a Negative
Binding Update via another MR when its egress interface fails, or
a de-registration BU only for some prefixes when one of the
ingress interfaces fails. The reference [3] gives some clue.
o When the MR is at home, the use of a dynamic routing protocol
between MR and HA instead of static routes on the HA, so the home
agent's routing table will be dynamically updated in case of
failure on the MR side. However our configurations does not
support the case when the MR that is at home and uses a dynamic
routing protocol moves in a foreign network. For that purpose,
the NEMO Basic Support specification [8] describes the support of
dynamic routing protocols between a MR and its HA. But as we
currently don't have such feature implemented, we could not test
it.
o A mechanism for the HA to choose a MR which is at home instead of
the one that is in a foreign network, if the topology allows this
choice. The solution depends on NEMO Basic Support and route
selection implementations. However, always choosing the MR that
is at home might not be the best solution. Some metrics could
help to choose the best path to the mobile network.
o A mechanism for the MR that is in a foreign network to deregister
its NEMO-prefix if it knows that at least one another MR is at
home, and register again when it learns that no MRs are at home
anymore. A coordination mechanism between MRs could help this
solution.
o The LFN may also prefer to choose the MR that is at home as exit
router. Cooperation between MRs or between the MR and the LFN
would help.
Kuntz, et al. Expires January 19, 2006 [Page 15]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
o One solution could be to use virtual home network in case of
multiple MRs. The reference [6] gives some clues in section 7,
and explains advantages and drawbacks of such a solution.
8. Case (2,1,2): Multiple MRs, Single HA, Multiple NEMO-Prefixes
8.1 Scenario
_
CN|_|---| _ _____
|-|_|-| |
_ | |
| <-p1 ___ |-|_|-| |-|
_ |------|_1_|-CoA1--| | | | _ |-
|_|-| ___ | | |-|_|-|
|------|_2_|-CoA2--| _ | | |
<-p2 |-|_|-|_____|
LFN MRs ARs Internet HA Home Network
(2,1,2) Multihomed Mobile Network
Each MR (MR1 and MR2) has one egress interface and advertises
different NEMO-Prefixes p1 and p2 on the mobile network. The home
agent has two binding cache entries: one for HoA1/CoA1/p1, and one
for HoA2/CoA2/p2. The HA acts as the default gateway on the home
link.
Notes:
o The LFN's default router can be either MR1 or MR2.
o The HA will forward packets to MR1 and MR2 according to the NEMO-
prefix registered in the binding cache for each MR.
o There are two different prefixes advertised in the mobile network.
The LFNs can configure two IPv6 global addresses: one for each
prefix advertised, and are reachable via these two addresses.
o A CN can reach the LFN via its two IPv6 addresses, but the path is
different whether which address is used to reach the LFN.
Kuntz, et al. Expires January 19, 2006 [Page 16]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
8.2 Results
8.2.1 With both MRs in a foreign network
First, the LFN uses the address built from the MNP p1 advertised by
MR1 as source address, and uses MR1 as default router. If a CN
communicates with the LFN using its address built from the MNP p1 as
destination address, the communication is symmetric. But if a CN
communicates with the LFN using its address built from the MNP p2 as
destination address, the communication path is asymmetrical. Ingress
filtering can occur on MR1 if it does not allow to forward packets
whose source address is not built from the MNP p1.
When the ingress or egress interface fails on MR2:
o If a CN communicates with the LFN with its address built from the
MNP p1, the communication does not stop, because both sides of the
communications go through MR1.
o If a CN communicates with the LFN with its address built from the
MNP p2, the CN cannot reach the LFN but the LFN can still reach
the CN as it uses MR1 as default router.
One way for the CN to reach the LFN is to change the destination
address, but the CN must be aware that the LFN is reachable via two
addresses, and address change would break all ongoing TCP
communications.
Another way is that the HA forwards all packets via the HA-MR1
tunnel. For this idea, the HA must be aware that MR1 and MR2 belong
to the same mobile network. The HA must also be aware when one of
MR2's interface fails: if MR2's egress interface fails, the binding
cache entry on the HA will be deleted when its lifetime expires. But
the HA has currently no way to know when MR2's ingress interface
fails.
When the ingress interface fails on MR1:
o The LFN does not receive router advertisement anymore from MR1, so
its default router will change to MR2. The address built from the
MNP p1 becomes deprecated and the one built from the MNP p2 is
preferred. The LFN is then able to reach the internet, but as the
source address changed, all ongoing TCP communications break.
o The CN cannot reach the LFN on its address built from the MNP p1,
but can reach it on its address built from the MNP p2 as soon as
the LFN changed its default router to MR2.
Kuntz, et al. Expires January 19, 2006 [Page 17]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
o If MR1's ingress interface recovers, MR2 is still the LFN's
default router. The communication may be asymmetrical if the LFN
uses the newly address built from the MNP p1 as source address.
If MR1's egress interface fails, the LFN cannot be aware of the
failure and will go on using MR1 as default router. Thus the LFN is
not reachable anymore to any of its addresses. One solution could be
that MR1 advertises RA with a lifetime set to 0 or to send ICMP
redirects to force the LFN to change its default router. Then LFN
could be at least reachable on its address built from the prefix
advertised by MR2.
Now, the LFN uses the address built from the MNP p1 advertised by MR1
as source address, and uses MR2 as default router.
o If MR2's ingress interface fails, the LFN will switch its default
router to MR1. The LFN will not be reachable at its address built
from the prefix advertised by MR2, but will be reachable on the
one built from the prefix advertised by MR1.
o If MR2's egress interface fails, the LFN will not be reachable at
any of its addresses. This case is similar to one above.
o If MR1's ingress or egress interface fails, the LFN will still be
reachable at its address built from the MNP p2 but not at the one
built from the MNP p1.
8.2.2 With MR2 at home and MR1 in a foreign network
Behavior will be basically the same as above, because instead of
having two different entries in the binding cache and two routes
towards a MR-HA tunnel, the home agent will have one entry in binding
cache for MR1 that is in foreign network, one route to the MNP p1
towards the MR1-HA tunnel, and one route to the MNP p2 via MR2
created by a dynamic routing protocol. A mechanism for the home
agent and the LFN to prefer the MR that is at home could be useful,
as discussed in section 7.3. The mechanisms to reduce the MRs'
failures seen in the case (2,1,1) can also apply here.
8.3 Potential problems and solutions
The LFN may use the address built from one of the prefix as a source
address and use the MR that advertises the other prefix as default
router. In this case we do not have ingress filtering issues on the
HA because packets from the LFN are encapsulated by the MR and
forwarded to the HA, and we only have one home agent for both MRs.
However ingress filtering may happen on the mobile router if it
Kuntz, et al. Expires January 19, 2006 [Page 18]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
filters the packets whose addresses are built from a prefix the MR is
not configured to serve.
Communications between a LFN and a CN can be asymmetrical in some
cases, regarding to the LFN's default router and the address it uses
to communicate with a CN.
In case of one of the MR failure, if the home agent knows that both
NEMO-prefixes are for the same mobile network, it can use the other
MR to reach the mobile network. MR1 could advertise to the HA the
NEMO-prefix that MR2 advertised (and conversely), so the HA would
have two binding cache entries and routes for the same prefixes, and
would be able to use a similar solution than for the (2,1,1) case.
With some policy mechanisms, the LFN could send packets with source
address built from the MNP p1 to MR1, and packets with source address
built from the MNP p2 to MR2. This could avoid ingress filtering
issues at the MR and the LFN could always reach or be reachable to
one of its address if one of the MR's interface fails.
In any cases, as raised in [3], section 4.3, if the LFN changes its
source address it used to send packets, ongoing transport sessions
without multihoming capabilities (such as TCP) are terminated.
9. Case (2,2,1): Multiple MRs, Multiple HAs, Single NEMO-Prefix
9.1 Scenario
_
CN|_|---| _ _____
|-|_|-| |
_ | |
| <-p1 ___ |-|_|-| |-| _
_ |------|_1_|-CoA1--| | | | _ |-|1|
|_|-| ___ | | |-|_|-| _
|------|_2_|-CoA2--| _ | | |-|2|
<-p1 |-|_|-|_____|
LFN MRs ARs Internet AR Home Network with 2 HAs
(2,2,1) Multihomed Mobile Network
Each MR (MR1 and MR2) has one egress interface and advertises the
same NEMO-Prefix p1 on the mobile network. Registering the same MNP
to two different home agents raise one issue: each HA has to
advertise a route to the MNP, which is a problem if each HA is in a
Kuntz, et al. Expires January 19, 2006 [Page 19]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
different domain. In this test we configure both HAs on the same
home link. They do not act as a gateway to the Internet. Both HAs
advertise a route to the MNP thanks to a dynamic routing protocol.
The access router on the home link can then build a route to the MNP
via one of the home agent.
9.2 Results
If one of the MR's egress interface fails, the HA where the MR is
registered will delete the corresponding binding cache entry once its
lifetime has expired, and remove the route installed by the mobility
daemon. As the HA is configured to announce kernel routes with the
dynamic routing protocol, the route to the MNP will not be announced
anymore. The AR will be able to change its default route to the MNP
via the other HA if needed. Thus the mobile network will still be
reachable. However, the LFN's default router may be the MR whose
egress interface failed. The failed MR should then advertise RA with
a lifetime set to 0 or send ICMP redirects when it detects a failure
on its egress interface.
If one of the MR's ingress interface fails, the LFN will be able to
choose the other MR as default router if needed. However, if all the
traffic to the MNP is forwarded by the access router to the HA whose
MR's ingress interface has failed, the mobile network will be
unreachable from the Internet. So, the MR whose ingress interface
has failed should deregister to its HA (at least as mobile router,
but it can still act as a mobile host). The HA would thus delete the
route to the MNP via the MR, and the same mechanism as above could
apply.
If one MR is in its home network, and the other MR is in a foreign
network, it may be better that all traffic goes through the MR that
is at home. Both HAs will have a route to the same MNP:
o Both HAs will have a route built from the dynamic routing protocol
running between the HA and the MR that is at home.
o One HA will also have a route built by the mobility daemon for the
MR that is in a foreign network.
If the HA that has both routes prefers the route built by the dynamic
routing protocol to the one built by the mobility daemon, then
whatever the AR chooses as next hop to the MNP, all traffic will go
through the MR that is at home.
9.3 Potential problems and solutions
How do the both home agents will delegate the same prefix to
Kuntz, et al. Expires January 19, 2006 [Page 20]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
different MRs? This is a prefix delegation issue. If we delegate a
prefix to different MRs manually, they will face a problem when the
MRs are split into different mobile networks.
10. Case (2,2,2): Multiple MRs, Multiple HAs, Multiple NEMO-Prefixes
10.1 Scenario
_ | _
CN|_|---| _ _____ |-|1|-|
|-|_|-| |-| |-
_ | |
| <-p1 ___ |-|_|-| |-|
_ |------|_1_|-CoA1--| | | | _ |-
|_|-| ___ | | |-|2|-|
|------|_2_|-CoA2--| _ | | |
<-p2 |-|_|-|_____|
LFN MRs ARs Internet HAs Home Networks
(2,2,2) Multihomed Mobile Network
Each MR (MR1 and MR2) has one egress interface and advertises a
different NEMO-Prefix on the mobile network. They register to a
different home agent. Each home agent acts as the default gateway on
its home link.
10.2 Results
If each MR takes care of one prefix, and registers to a different HA,
there is nothing to add about the problems we can face if we have
ingress or egress interface failures on one MR. However, solutions
to the problem are more complex since there are two HAs: for
instance, one MR may have problem to register the other MR's MNP to
the other HA (as suggested in section 8.3) due to access control and
security issues.
As raised in [3], if one MR takes care of more than one prefix,
problems issued from this configuration can be decomposed into
problems from others cases, especially (2,1,2).
10.3 Potential problems and solutions
As raised in [3] section 4.3, when the two tunnels between MRs and
HAs end at different home agents, and each HA registers a different
NEMO-Prefix, ingress filtering may occur at the HA. According to [8]
Kuntz, et al. Expires January 19, 2006 [Page 21]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
section 9, the HA must check whether the source address of the inner
IPv6 header is a topologically correct address with respect to the
IPv6 prefixes used in the mobile network. A solution to this problem
could be source address switching on the LFN or nested tunnels, as
described in [3] appendix B.
11. Conclusions
This document investigates the issues for practical deployment of
NEMO basic support. It focuses on technical issues as well as
implementation issues from multiple MRs, multiple HAs and multiple
MNPs topologies. The tests we performed are work in progress. We
are testing other cases and check if additional issues appear with
the topologies presented in this document.
12. Changes
12.1 Changes from version 01 to 02
Added test cases (1,1,1), (1,1,2), (1,2,2), (2,2,1).
Updated test cases (1,2,1), (2,1,1), (2,1,2), (2,2,2).
Some tests now support Multiple Care-of Addresses registration.
Updated References list.
12.2 Changes from version 00 to 01
Editorial changes
Added some text about existing NEMO Basic Support implementations.
Updated References list.
13. References
[1] Ernst, T., "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-04 (work in progress),
February 2005.
[2] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-03 (work in progress),
February 2005.
[3] Ernst, T., "Analysis of Multihoming in Network Mobility
Support", draft-ietf-nemo-multihoming-issues-02 (work in
progress), February 2005.
Kuntz, et al. Expires January 19, 2006 [Page 22]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
[4] Wakikawa, R., "Multiple Care-of Addresses Registration",
draft-wakikawa-mobileip-multiplecoa-04 (work in progress),
June 2005.
[5] Ernst, T., "Goals and Benefits of Multihoming",
draft-ernst-generic-goals-and-benefits-01 (work in progress),
February 2005.
[6] Thubert, P., Wakikawa, R., and V. Devarapalli, "NEMO Home
Network models", draft-ietf-nemo-home-network-models-04 (work
in progress), June 2005.
[7] Montavont, N., Wakikawa, R., and T. Ernst, "Analysis of
Multihoming in Mobile IPv6",
draft-montavont-mobileip-multihoming-pb-statement-04 (work in
progress), June 2005.
[8] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[9] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[10] WIDE, "The Nautilus6 Project", URL http://www.nautilus6.org,
July 2005.
[11] WIDE, "The KAME Project", URL http://www.kame.net, July 2005.
[12] IETF, "The NEMO Working Group",
URL http://www.ietf.org/html.charters/nemo-charter.html,
July 2005.
[13] Mitsuya, K., "Nautilus6 NEMO Basic Support implementation",
Implementation
Report http://www.nautilus6.org/implementation/atlantis.html,
July 2004.
[14] WIDE, "The WIDE Project", URL http://www.wide.ad.jp/,
July 2005.
[15] WIDE, "SHISA, an implementation of MIPv6/NEMO",
URL http://www.mobileip.jp/, July 2005.
[16] Go-Core and Nautilus6, "NEPL, NEMO Platform for Linux",
URL http://www.mobile-ipv6.org/, July 2005.
[17] Go-Core, "MIPL, Mobile IPv6 for Linux",
Kuntz, et al. Expires January 19, 2006 [Page 23]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
URL http://www.mobile-ipv6.org/, July 2005.
[18] Kuntz, R., "NEMO Basic Support implementation tests at the 6th
IPv6 TAHI Interoperability Test Event", Interoperability tests
report http://www.nautilus6.org/doc/
tc-nemo-tahi-interop-20050207-KuntzR.txt, January 2005.
[19] Ernst, T. and J. Charbon, "Multihoming with NEMO Basic
Support", Proceedings First International Conference on Mobile
Computing and Ubiquitous Networking (ICMU), January 2004.
[20] Lucian, S., Bonnin, J-M., Guillouard, K., and B. Stevant,
"Towards a Highly Adaptable User-Centric Terminal
Architecture", Proceedings 7th International Symposium on
Wireless Personal Multimedia Communication (WPMC04),
September 2004.
Authors' Addresses
Romain Kuntz
WIDE at Keio University
Jun Murai Lab., Keio University.
K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
Kawasaki, Kanagawa 212-0054
Japan
Phone: +81-44-580-1600
Fax: +81-44-580-1437
Email: kuntz@sfc.wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~kuntz/
Manabu Tsukada
WIDE at Keio University
Jun Murai Lab., Keio University.
K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
Kawasaki, Kanagawa 212-0054
Japan
Phone: +81-44-580-1600
Fax: +81-44-580-1437
Email: tu-ka@sfc.wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~tu-ka/
Kuntz, et al. Expires January 19, 2006 [Page 24]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
Eun Kyoung Paik
KT
Portable Internet Team, Convergence Lab., KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
Phone: +82-2-526-5233
Fax: +82-2-526-5200
Email: euna@kt.co.kr
URI: http://mmlab.snu.ac.kr/~eun/
Ernst Thierry
WIDE at Keio University
Jun Murai Lab., Keio University.
K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
Kawasaki, Kanagawa 212-0054
Japan
Phone: +81-44-580-1600
Fax: +81-44-580-1437
Email: ernst@sfc.wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~ernst/
Koshiro Mitsuya
WIDE at Keio University
Jun Murai Lab., Keio University.
K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
Kawasaki, Kanagawa 212-0054
Japan
Phone: +81-44-580-1600
Fax: +81-44-580-1437
Email: mitsuya@sfc.wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~mitsuya/
Kuntz, et al. Expires January 19, 2006 [Page 25]
Internet-Draft Multiple MRs and Multiple MNPs July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kuntz, et al. Expires January 19, 2006 [Page 26]
