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]