NEMO Working Group R. Kuntz Internet-Draft WIDE at Keio University Expires: January 10, 2005 E. Paik Seoul National University M. Tsukada T. Ernst K. Mitsuya WIDE at Keio University July 12, 2004 Evaluating Multiple Mobile Routers and Multiple NEMO-Prefixes in NEMO Basic Support draft-kuntz-nemo-multihoming-test-00.txt Abstract This document describes the tests performed and results obtained with multihomed mobile networks managed by NEMO Basic Support. We have particularly analyzed mobile networks with multiple mobile routers and mobile networks with multiple NEMO-Prefixes. NEMO Working Group R. Kuntz Internet-Draft WIDE at Keio University Expires: January 10, 2005 E. Paik Seoul National University M. Tsukada T. Ernst K. Mitsuya WIDE at Keio University July 12, 2004 Evaluating Multiple Mobile Routers and Multiple NEMO-Prefixes in NEMO Basic Support draft-kuntz-nemo-multihoming-test-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 10, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes the tests performed and results obtained with multihomed mobile networks managed by NEMO Basic Support. We have particularly analyzed mobile networks with multiple mobile routers Kuntz, et al. Expires January 10, 2005 [Page 1] Internet-Draft Multiple Mobile Routers and Multiple NEMO-Prefixes July 2004 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 4. Case (1,1,2): Single MR, Single HA, Multiple NEMO-Prefixes . . 5 4.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3 Potential issues . . . . . . . . . . . . . . . . . . . . . 5 5. Case (1,2,1): Single MR, Multiple HAs, Single NEMO-Prefix . . 5 6. Case (1,2,2): Single MR, Multiple HAs, Multiple NEMO-Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Case (2,1,1): Multiple MRs, Single HA, Single NEMO-Prefix . . 6 7.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.2.1 With both MRs in a foreign network . . . . . . . . . . 7 7.2.2 With MR2 at home and MR1 in a foreign network . . . . 10 7.3 Potential problems and solutions . . . . . . . . . . . . . 12 8. Case (2,1,2): Multiple MRs, Single HA, Multiple NEMO-Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.2.1 With both MRs in a foreign network . . . . . . . . . . 14 8.2.2 With MR2 at home and MR1 in a foreign network . . . . 14 8.3 Potential problems and solutions . . . . . . . . . . . . . 15 9. Case (2,2,1): Multiple MRs, Multiple HAs, Single NEMO-Prefix . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.3 Potential problems and solutions . . . . . . . . . . . . . 16 10. Case (2,2,2): Multiple MRs, Multiple HAs, Multiple NEMO-Prefixes . . . . . . . . . . . . . . . . . . . . . . . 16 10.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.3 Potential problems and solutions . . . . . . . . . . . . . 16 11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 17 Kuntz, et al. Expires January 10, 2005 [Page 2] Internet-Draft Multiple Mobile Routers and Multiple NEMO-Prefixes July 2004 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 20 Kuntz, et al. Expires January 10, 2005 [Page 3] Internet-Draft Multiple Mobile Routers and Multiple NEMO-Prefixes July 2004 1. Introduction In this document we study the support of multihoming in the NEMO [11] context. We present the results of tests performed on NEMO Basic support [1] 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 [6][7]. The terminology used is this memo is defined in [3] and [4] whereas the multihomed configurations are classified according to the taxonomy defined in [6]. We first give a short description of our testbed and implementation before describing our tests on distinct configurations, following the same order of the classification defined in [6]. Some configurations remain to be tested. 2. Testing Environment The multihoming tests were performed on the indoor testbed of the Nautilus6 Project [9]. The indoor testbed allows us to test protocol under development. It is composed of two mobile routers and two home agents, each running NetBSD 1.6.1 and NEMO Basic Support. Several LFNs are located in each mobile network. Additionnaly, 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. Our implementation of NEMO Basic Support [12] is based on draft-02 of NEMO Basic Support [1] and is presented as an extension of KAME MIPv6 [10] 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 MR switches their mode by configuration. It also supports DHAAD and IPSec protection between HA and MR. This implementation is 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. It supports basic Multiple I/F switching, we can put a preference on each I/F. Additionally, interoperability tests conducted with an implementation from Nokia and another implementation from Keio University were successful. The second implementation of Keio University is based on a variant of KAME (i.e. SFCMIP). To avoid confusion between implementations, please refers to ours as the "Nautilus6 implementation" [12]. Kuntz, et al. Expires January 10, 2005 [Page 4] Internet-Draft Multiple Mobile Routers and Multiple NEMO-Prefixes July 2004 3. Case (1,1,1): Single MR, Single HA, Single Prefix This case is out of scope of the present document since we are only interested in multiple Mobile Routers and multiple NEMO-prefixes. 4. Case (1,1,2): Single MR, Single HA, Multiple NEMO-Prefixes 4.1 Scenario _____ _ | | _ | p1 __ |-|_|-| |-| |_|-| <- | |-CoA1--| | | | _ |- |------| | | | |-|_|-| | <- |__|-CoA2--| _ | | | p2 |-|_|-|_____| LFN MR ARs Internet HA Home Network (1,1,2) Multihomed Mobile Network MR has two egress interfaces and advertises two different NEMO-Prefixes on its ingress interface(s) to the Mobile Network. In this test, we can expect to register both NEMO-prefixes for each Care-of Address to the Home Agent, or to register CoA1 associated with NEMO-prefix p1 and CoA2 associated with NEMO-prefix p2 to the Home Agent. 4.2 Results At the moment, the NEMO Basic Support implementation we use does not allow to register multiple NEMO-prefixes for the same Care-of Address. Also, there are no standards solutions yet for multiple Care-of Addresses management. Thus this test is still in progress. 4.3 Potential issues If we register more than one Care-of Address to the Home Agent, we need to select which Care-of Address to use for each flow. 5. Case (1,2,1): Single MR, Multiple HAs, Single NEMO-Prefix This case is out of scope of the present document since we are only interested in multiple Mobile Routers and multiple NEMO-prefixes. Kuntz, et al. Expires January 10, 2005 [Page 5] Internet-Draft Multiple Mobile Routers and Multiple NEMO-Prefixes July 2004 6. Case (1,2,2): Single MR, Multiple HAs, Multiple NEMO-Prefixes As the case (1,1,2) is not solved yet, this test is for a later session. 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: _ CN|_|---| _ _____ |-|_|-| | _ | | | <-p1 ___ |-|_|-| |-| _ |------|_1_|-CoA1--| | | | _ |- |_|-| ___ | | |-|_|-| |------|_2_|-CoA2--| _ | | | <-p1 |-|_|-|_____| LFN MRs ARs Internet HA Home Network (2,1,1) Multihomed Mobile Network, both MR in foreign networks Each MR (MR1 and MR2) has one egress interface and advertise the same NEMO-Prefix p1 on the mobile network. When HA receives a BU about a prefix which is already in cache from another MR, HA updates the Prefix Table with the new prefix. In this case, the Home agent has two entries in its binding cache: one for CoA1/p1, and one for CoA2/ p1. o LFN's default router can be either MR1 or MR2. o HA can forward packets to either MR1 or MR2. o We test the following interface failures: MR2 egress, MR2 ingress, MR1 egress, and MR1 ingress interface. Notes: o In the implementation we use, in the case we have several entries in the Binding Cache with the same NEMO-Prefix, the Home Agent always selects the entry that was created at first. Kuntz, et al. Expires January 10, 2005 [Page 6] Internet-Draft Multiple Mobile Routers and Multiple NEMO-Prefixes July 2004 o The LFN's routers list contains both MRs. Its default router is randomly selected, the LFN will then always uses it unless its default router is not reachable anymore. o When two entries are in the Home Agent Binding Cache with the same NEMO-prefix (for instance one for MR1, and one for MR2), if the one used by the Home Agent to forward packets to the NEMO-prefix is deleted due to a timeout (let's say the one for MR1), the another entry is only used when a BU from MR2 updates it. This is an implementation issue, but it explains that during this interval there is either a loop between HA and its default route (if HA has no route to MR1), or the CN receives unreachability messages from HA if a route is in HA's routing table. We will then test with one MR in a foreign network, and the second MR at home: _ 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 o LFN default router can be either MR1 or MR2. o We test the following interface failures: MR2 egress, MR2 ingress, MR1 egress, and MR1 ingress interface. 7.2 Results 7.2.1 With both MRs in a foreign network LFN's default router is MR1 and HA forwards packets to the Mobile Network via MR1. We first unplug MR2's egress interface. This is a trivial case: Kuntz, et al. Expires January 10, 2005 [Page 7] Internet-Draft Multiple Mobile Routers and Multiple NEMO-Prefixes July 2004 o Before we unplug: the path from CN to LFN and from LFN to CN is symetric (via MR1). o After we unplug (but before the binding cache entry for MR2 is deleted on HA): if CN tries to reach MR2 Home Address, HA advertises to CN that MR2 Home Address is unreachable. o LFN is still reachable via MR1 before and after MR2 binding lifetime expires on HA. o LFN can still reach nodes outside of the mobile network. o After we plug in again MR2's egress interface, CN can reach MR2 Home Address again. We then unplug MR2's ingress interface. This is also a trivial case: o Before we unplug: the path from CN to LFN and from LFN to CN is symetric (via MR1) o After we unplug: LFN is still reachable via MR1 and it can still reach nodes outside the mobile network. We then unplug MR1's egress interface: o Before we unplug: the path from CN to LFN and from LFN to CN is symetric (via MR1) o After we unplug, but before MR1 binding lifetime expires on HA binding cache: the LFN is not reacheable anymore, a traceroute stops at HA. o After MR1 entry is deleted in HA binding cache: there is a loop between HA and its default router, because in our test, HA does not have any route to the NEMO-prefix advertised by MR1. o Few seconds later, when MR2 updates its binding cache entry by sending a BU to the HA, HA uses MR2 entry to forward packets to the mobile network. LFN receives our packets but cannot reply, because its default router is still MR1. o After we plug in again MR1's egress, HA still uses MR2 to forward packets to the mobile network, and LFN still uses MR1 as its default router: communication is not symetric anymore, it uses different path from LFN to CN and from CN to LFN. A mechanism for the HA to switch quickly to another MR could be useful. This is a NEMO Basic Support implementation issue. A Kuntz, et al. Expires January 10, 2005 [Page 8] Internet-Draft Multiple Mobile Routers and Multiple NEMO-Prefixes July 2004 mechanism for the LFN to switch quickly to another default router is also required. We then unplug MR1's ingress interface: o Before we unplug: the path from CN to LFN and from LFN to CN is symetric (via MR1) o After we unplug: CN gets an "Destination unreachable: Address unreachable" message from MR1 if CN tries to send packets to LFN. o After few seconds, LFN change its default router: it can send packets to CN, but the reply does not reach LFN because HA still forward packets to the mobile network via MR1. o After we plug in again MR1's ingress interface: CN can reach LFN and LFN can reach CN but communication between CN and LFN is now asymetric, because LFN still uses MR2 as its default router. An MR should be able to deregister itself towards its HA when it detects a failure on its interface. Now LFN's default router is MR2 and HA forwards packets to the Mobile Network via MR1. We first unplug MR1's egress interface: o Before we unplug: the path from CN to LFN and from LFN to CN is asymetric. o After we unplug, but before MR1 Binding Cache entry is deleted in HA Binding Cache: LFN can reach CN (because it uses MR2 as default router) but CN cannot reach LFN, so communication is broken. o After MR1's binding entry is deleted in HA Binding Cache: there is a loop between HA and its default router because in our test HA does not have any route to the NEMO-prefix. The loop stops when MR2 updates its entry in HA Binding Cache by sending a BU. LFN and CN can then reach each others, communication is re-established, and symetric. o If we plug in again MR1's egress, HA creates a new binding cache entry for MR1 but still uses MR2 to forward packets to the Mobile Network. Communication path between CN and LFN is still symetric. We then unplug MR1's ingress interface. o Before we unplug: the path from CN to LFN and from LFN to CN is Kuntz, et al. Expires January 10, 2005 [Page 9] Internet-Draft Multiple Mobile Routers and Multiple NEMO-Prefixes July 2004 asymetric. o After we unplug: CN receives a "Destination unreachable: Address unreachable" message from MR1 if it tries to reach LFN. LFN can reach CN but CN cannot reach LFN. o After we plug in MR1's ingress interface again, communication between CN and LFN is reestablished and uses the same path as before. We then unplug MR2's egress interface. o Before we unplug: the path from CN to LFN and from LFN to CN is asymetric. o After we unplug: CN can reach LFN but LFN cannot reach CN anymore. o Binding cache entry for MR2 on HA is deleted when the binding lifetime expires. Then it is created again when we replug MR2's egress interface (which is still in a foreign network). HA still uses MR1 to forward packets to the mobile network. o After we plug in MR2's egress again, communication between CN and LFN is restablished and uses the same path as before. We then unplug MR2's ingress interface. o Before we the unplug: path from CN to LFN and from LFN to CN is asymetric. o After we unplug, CN can reach LFN but LFN cannot reach CN before it switches its default router to MR1. o Few seconds later, LFN switches its default router to MR1, communication is restablished and is symetric. o After we plug in again MR2's ingress, CN still uses MR1 as default router. 7.2.2 With MR2 at home and MR1 in a foreign network Notes: o HA has a static route in its routing table to the NEMO-prefix p1 via MR2. o In our implementation, the Binding Cache on HA is checked before Kuntz, et al. Expires January 10, 2005 [Page 10] Internet-Draft Multiple Mobile Routers and Multiple NEMO-Prefixes July 2004 the routing table. We first unplug MR2's egress interface. o Before we unplug, HA always forwards to MR1 because HA has an entry in its Binding cache for MR1. o After we unplug, packets for the Mobile Network are still forwarded by HA via MR1 so there are no problems if LFN has MR1 as default router, otherwise LFN cannot reach outside the Mobile Network. We then unplug MR2's ingress interface. o Before we unplug, HA always forwards to MR1 because HA has an entry in its Binding cache for MR1. o After we unplug, packets for the Mobile Network are forwarded by HA via MR1 so there are no problems because if LFN's default router is MR2, it will change to MR1 after few seconds. o In this case the communication between CN and LFN will be symetric after unplug. We then unplug MR1's egress interface. o Before we unplug, HA always forwards to MR1 because HA has an entry in its Binding cache for MR1. o After we unplug, the Mobile Network is unreachable while the entry for MR1 exists in HA's binding cache . o Once the timeout reaches 0 for MR1 entry in HA binding cache, the entry is deleted, then HA uses its static route via MR2 to route traffic for NEMO-prefix p1. o In this case, the Mobile Network reachability depends on HA's routing table and LFN's default router. We then unplug MR1's ingress interface. o Before we unplug, HA always forwards to MR1 because HA has an entry in its Binding cache for MR1. o After we unplug, CN is not able to reach LFN anymore. LFN changes its default router to MR2 if its default router was MR1. So LFN can reach outside of the mobile network but nobody outside of the mobile network can reach LFN. Kuntz, et al. Expires January 10, 2005 [Page 11] Internet-Draft Multiple Mobile Routers and Multiple NEMO-Prefixes July 2004 A solution to this issue could be that MR1 advertises its Home Agent to delete its entry in the binding cache, but it works only if HA's routing table has a route to NEMO-prefixe p1 via MR2. 7.3 Potential problems and solutions Regarding to theses 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 symetric 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 MR notices a failure. For exemple a Negative Binding Update via another MR when egress fails, or a de-registration BU only for some prefixes when one of the ingress fails. The reference [6] gives some clue. o Using a dynamic routing protocol between MR and HA instead of static routes on HA, so the Home Agent routing table will be quickly updated in case of failure on the MR side. o A mechanism for the HA to choose an MR which is at home instead of an MR in a foreign network, if the topology allows this choice. The solution depends on the NEMO Basic Support implementation, because the Home Agent can either use only the routing table, or only the binding cache, or both to route packets 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 MR are at home anymore. A coordination mechanism between MRs could help this solution. One other solution could be to forbid home networks in case of multiple MRs. The reference [8] gives some clues in section 6, and explains advantages and drawbacks of such a solution. 8. Case (2,1,2): Multiple MRs, Single HA, Multiple NEMO-Prefixes Kuntz, et al. Expires January 10, 2005 [Page 12] Internet-Draft Multiple Mobile Routers and Multiple NEMO-Prefixes July 2004 8.1 Scenario _ CN|_|---| _ _____ |-|_|-| | _ | | | <-p1 ___ |-|_|-| |-| _ |------|_1_|-CoA1--| | | | _ |- |_|-| ___ | | |-|_|-| |------|_2_|-CoA2--| _ | | | <-p2 |-|_|-|_____| LFN MRs ARs Internet HA Home Network (2,1,2) Multihomed Mobile Network o LFN's default router can be either MR1 or MR2. o HA will forward packets to MR1 and MR2 depending on the NEMO-prefix registered in the binding cache for each MR. o We test the following interface failures: MR2 egress, MR2 ingress, MR1 egress, MR1 ingress. Notes: o There are two different prefixes advertised in the mobile network. o LFN configures two IPv6 global adresses: one for each prefix advertised, and is reachable via these two addresses. LFN default router is chosed randomly. o HA has one entry in its binding cache per prefix, it means one entry for each MR. o CN can reach LFN via its two IPv6 addresses, but the path is different whether which address is used to reach LFN. o LFN can 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. It this case we do not have ingress filtering issues because packets from LFN are encapsulated by the MR and forwarded to HA, and we only have one Home Agent for both MRs. o Communication is asymetric in some cases, regarding to LFN default Kuntz, et al. Expires January 10, 2005 [Page 13] Internet-Draft Multiple Mobile Routers and Multiple NEMO-Prefixes July 2004 router. o As raised in [6], section 4.5, if LFN changes its source address it used to send packets, transport sessions without multihoming capabilities (such as TCP) are terminated. 8.2 Results 8.2.1 With both MRs in a foreign network We first unplug MR2's egress interface: o CN will not be able to reach LFN on one of its address (the one built from the prefix advertised by MR2) and will be able to reach LFN on its other address only if LFN's default router is MR1. MR2 should stop to advertise its prefix, so LFN stops using the address and change its default router, so then CN will be able to reach LFN on at least one of its address. o When timeout reaches 0 in binding cache on HA for MR2 entry, the entry is deleted, and there is a loop between HA and its default router if HA does not have any route to MR2. If the Home Agent knows that both NEMO-prefixes are for the same mobile network, it should use another MR to reach the Mobile Network. MR1 could also advertise to HA the NEMO-prefix that MR2 advertised, so HA will have two entries for the same prefixes, and we will be able to use a similar solution than for the (2,1,1) case. Also, If CN knows that LFN is reachable via two addresses, it can use the second one if the first one is unreachable (but it means that we need a new macanism on CN). We then unplug MR2's ingress interface: o CN will not be able to reach LFN on one of its address. o But CN can reach LFN using its other address, because LFN will change its default router quickly if its default router was the one which ingress interface failed. Unplugging MR1's egress or ingress is a symetric case as the one presented above. 8.2.2 With MR2 at home and MR1 in a foreign network Behaviour will be basically the same as above, because instead of having two differents entries in the binding cache, the Home Agent Kuntz, et al. Expires January 10, 2005 [Page 14] Internet-Draft Multiple Mobile Routers and Multiple NEMO-Prefixes July 2004 will have one entry in binding cache for MR1 that is in foreign network, and one entry in the routing table for MR2 that is at home. A mechanism for the Home Agent and the LFN to prefer the MR that is at home could be useful, but as discussed in section 6.3, the solution depends on NEMO Basic Support implementation. The others mechanisms to reduce MRs failures seen in the case (2,1,1) can also apply here. 8.3 Potential problems and solutions Regarding to theses tests, we can discuss about these improvements: o Transport sessions are broken if LFN changes its source address to send packets. To avoid source address switching on LFN, MR1 could advertise on the mobile network and to the Home Agent the NEMO-prefix that MR2 advertises, and conversely. The Home Agent will then have two entries for the same NEMO-prefixes, and we will be able to use a similar solution than for the (2,1,1) case in case of failure of one MR. o A MR whose egress interface fails should stop to advertise its prefix(es) on the mobile network. 9. Case (2,2,1): Multiple MRs, Multiple HAs, Single NEMO-Prefix 9.1 Scenario _ | _ CN|_|---| _ _____ |-|1|-| |-|_|-| |-| |- _ | | | <-p1 ___ |-|_|-| |-| _ |------|_1_|-CoA1--| | | | _ |- |_|-| ___ | | |-|2|-| |------|_2_|-CoA2--| _ | | | <-p1 |-|_|-|_____| LFN MRs ARs Internet HAs Home Networks (2,2,1) Multihomed Mobile Network As raised in [6], we have to check what happens when multiple home agents in different domains advertise routes to the same NEMO-prefix. Kuntz, et al. Expires January 10, 2005 [Page 15] Internet-Draft Multiple Mobile Routers and Multiple NEMO-Prefixes July 2004 9.2 Results This case needs more investigation before we can test it. For a later session. 9.3 Potential problems and solutions How do the both home agents will delegate the same prefix to 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 splitted 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 10.2 Results If each MR takes care of one prefix, and register to separate HA, there is nothing to add about the problems we can face if we have ingress or egress interface failures on one MR. As raised in [6], if one MR takes care of more than one prefix, problems issues from this configuration can be decomposed into problems from others cases, especially (2,1,2). 10.3 Potential problems and solutions As raised in [6] section 4.5, 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. According to [1] section 9, the HA must check whether the source address of the inner IPv6 Kuntz, et al. Expires January 10, 2005 [Page 16] Internet-Draft Multiple Mobile Routers and Multiple NEMO-Prefixes July 2004 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 [6] 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 and multiple NEMO-prefix 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 References [1] Devarapalli, V., "Network Mobility (NEMO) Basic Support Protocol", draft-ietf-nemo-basic-support-03 (work in progress), June 2004. [2] Ernst, T., "Network Mobility Support Goals and Requirements", draft-ietf-nemo-requirements-02 (work in progress), February 2004. [3] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-01 (work in progress), February 2004. [5] Ernst, T., "Goals and Benefits of Multihoming", draft-multihoming-generic-goals-and-benefits-00 (work in progress), February 2004. [6] Ng, C., Paik, E. and T. Ernst, "Multihoming Issues in Network Mobility Support", draft-ietf-nemo-multihoming-issues-00 (work in progress), July 2004. [7] Ernst, T. and J. Charbon, "Multihoming with NEMO Basic Support", Proceedings First International Conference on Mobile Computing and Ubiquitous Networking (ICMU), January 2004. [8] Thubert, P., Wakikawa, R. and V. Devarapalli, "NEMO Home Network models", draft-ietf-nemo-home-network-models-00 (work in progress), April 2004. [9] WIDE, "The Nautilus6 Project", URL http://www.nautilus6.org, Kuntz, et al. Expires January 10, 2005 [Page 17] Internet-Draft Multiple Mobile Routers and Multiple NEMO-Prefixes July 2004 June 2004. [10] WIDE, "The KAME Project", URL http://www.kame.net, June 2004. [11] IETF, "The NEMO Working Group", URL http://www.ietf.org/html.charters/nemo-charter.html, June 2004. [12] Mitsuya, K., "Nautilus6 NEMO Basic Support implementation", Implementation Report http://www.nautilus6.org/doc/ir-nemo-bs-20040712-MitsuyaK.pdf, July 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/ Paik, Eun Kyoung Seoul National University Multimedia and Mobile communications Lab., Seoul National Univ. Shillim-dong, Kwanak-gu Seoul 151-744 Korea Phone: +82-2-880-1832 Fax: +82-2-872-2045 EMail: eun@mmlab.snu.ac.kr URI: http://mmlab.snu.ac.kr/~eun/ Kuntz, et al. Expires January 10, 2005 [Page 18] Internet-Draft Multiple Mobile Routers and Multiple NEMO-Prefixes July 2004 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/ 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 10, 2005 [Page 19] Internet-Draft Multiple Mobile Routers and Multiple NEMO-Prefixes July 2004 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 (2004). 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 10, 2005 [Page 20]