Network Mobility Working Group C. W. Ng Internet-Draft Panasonic Singapore Labs Expires: August 2003 T. Tanaka Panasonic Mobile Communications February 2003 Multi-Homing Issues in Bi-Directional Tunneling draft-ng-nemo-multihoming-issues-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract This document describes deployment scenario of multi-homed NEMO and attempts to identify issues that arises when supporting multi-homing in NEMO. This document also proposes an approach to facilitate multi-homing in NEMO. However, it is not the objective of this memo to define a specification for multi-homing support in NEMO. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Ng & Tanaka Expires - August 2003 [Page 1] Internet-Draft Multi-homing Issues in NEMO February 2003 Table of Contents 1. Introduction...................................................3 1.1. Terms Used................................................5 1.2. Organization..............................................5 2. Multi-Homing in NEMO...........................................6 2.1. Deployment Scenarios of Multi-homed NEMO..................6 2.1.1. Single Mobile Router with Multiple Egress Interfaces Bound to a Single Home Agent................................6 2.1.2. Single Mobile Router with Multiple Egress Interfaces Bound to Different Home Agents..............................7 2.1.3. Multiple Mobile Routers..............................8 2.2. Issues of Multi-Homing in NEMO............................9 3. Using Multi-Homing Features in Bi-Directional Tunnels.........11 3.1. Detecting Presence of Alternate Routes...................11 3.2. Re-Establishment of Bi-Directional Tunnels...............12 3.2.1. Using Alternate Egress Interface....................12 3.2.2. Using Alternate Mobile Router.......................12 3.3. To Avoid Tunneling Loop..................................13 3.4. Other Considerations.....................................13 4. Security Considerations.......................................14 References.......................................................14 Author's Addresses...............................................16 Ng & Tanaka Expires - August 2003 [Page 2] Internet-Draft Multi-homing Issues in NEMO February 2003 1. Introduction The problem of Network Mobility Support (NEMO) is identified in various previous works [3,4,5,6]. In essence, the problem of network in motion is to provide continuous Internet connectivity to nodes in a network that moves as a whole. Nodes within the network that moves may not be aware of the network changing its point of attachment to the Internet. This differs from the traditional problem of mobility support as addressed by Mobile IPv4 [7] in Internet Protocol version 4 (IPv4) [8] and Mobile IPv6 [9] in Internet Protocol version 6 (IPv6) [10]. In Mobile IP, each mobile node has a permanent home domain. When the mobile node is attached to its home network, it is assigned a permanent global address known as a home-address (HoA). When the mobile node is away, i.e. attached to some other foreign networks, it is usually assigned a temporary global address known as a care-of- address (CoA). The idea of mobility support is such that the mobile node can be reached at the home-address even when it is attached to other foreign networks. This is done in [7,9] with the introduction of an entity at the home network known as a home agent (HA). Mobile nodes register their care-of-addresses with the home agents using messages known as Binding Updates. The home agent is responsible to intercept messages that are addressed to the mobile node's home- address, and forward the packet to the mobile node's care-of-address using IP-in-IP Tunneling [11,12]. Extending the concept of mobility support for individual hosts to mobility support for a network of nodes, the objective of a network in motion solution is to provide a mechanism where nodes in a mobile network can be reached by their permanent addresses, no matter where on the Internet the mobile network is attached to. There exist a few prior attempts to provide network mobility support, most of them based on using bi-directional tunnels between the mobile routers and the home agents of the mobile routers [13,14,15,16,17]. In bi-directional tunnels between mobile routers and home agents, the mobile router controlling a mobile network performs routing of packets to and from the mobile network when it is in its home domain. When the mobile router and its mobile network move to a foreign domain, the mobile router registers its care-of-address with its home agent. An IP-in-IP tunnel is then set up between the mobile router and the home agent. Every packet going to the mobile network will be intercepted by the home agent and forwarded to the mobile router through the IP-in-IP tunnel. The mobile router then forwards the packet to a host in its mobile network. When a node in its mobile network wishes to send a packet out of the network, the mobile router intercepts the packet and forward the packet to the home agent Ng & Tanaka Expires - August 2003 [Page 3] Internet-Draft Multi-homing Issues in NEMO February 2003 through the IP-in-IP tunnel. The home agent then sends the packet out to the intended recipient. However, the simple approach of bi-directional tunnel does not cater well to other powerful features of IPv4 and IPv6, such as multi- homing. A network in motion can be multi-homed if there exist a plurality of egress interfaces that offer independent routes to the global Internet. If all of these interfaces belong to the same mobile router, then only the mobile router is multi-homed. The mobile network nodes behind the mobile router see only one egress router, thus they are not multi-homed. On the other hand, if these interfaces belong to separate routers, then the mobile network nodes will see different egress routers and can attach to more than one of these egress routers simultaneously. These mobile network nodes are thus multi-homed themselves. Mobile networks typically have wireless connection to the global network. Though wireless technology has improved tremendously over the recent years, it is still more prone to channel instability and noise when compared to wired networks. One of the advantages of multi-homing is that mobile network nodes can use an alternative path to reach and be reached by the global Internet when one of its uplink is down. This is extremely useful for wireless-based mobile nodes, as it provides a back up mechanism to the unstable wireless uplink. However, with bi-directional tunneling mechanism employed by mobile routers, nodes only chose one mobile router as their default router. When this mobile router loses its connection to the global Internet, it can no longer maintain a tunnel with its home agent. Thus all nodes that made use of the mobile router will lose their connectivity to the global network as well, even though there may exits another mobile router on the same network that has an active link to the global Internet. Mobile network nodes may eventually realize that their default router no longer has a route to the global network, and select an alternate mobile router as their default router. Such a scheme relies on the mobile network nodes to perform their own route discovery. It adds processing load to mobile network nodes, which may have very limited processing powers (e.g. embedded devices), and incurs additional delays (for the mobile network nodes to realize their current default route is down). In addition, different mobile routers will advertise different subnet prefixes, and thus when mobile nodes eventually switch their default routers, they will have to use different care- of-addresses. This requires sending of binding updates to their home-agents, further increasing the lag of recovery. Ng & Tanaka Expires - August 2003 [Page 4] Internet-Draft Multi-homing Issues in NEMO February 2003 1.1. Terms Used It is assumed that readers are familiar with the NEMO terminology described in [18]. In addition, the following definitions of terms are used in this memo: Alternate Mobile Router This term is used when discussing the behaviour of a mobile router. It refers to another mobile router that is connected to the same mobile network and has an independent route to the global Internet. Alternate Egress Interface This term is used when discussing the behaviour of a mobile router with multiple egress interfaces. It refers to another egress interface that is connected to the global Internet. Failed Egress Interface This term refers to the egress interface of a mobile router that has lost its connection to the global Internet. 1.2. Organization In the remaining portions of this memo, we will first describe the motivations and scenarios for deploying multi-homed mobile networks in Section 2. The issues in using bi-directional tunneling in a multi-homed mobile network will also be described. In Section 3, we explore into possible solutions to the problems listed in Section 2, and investigate methods of optimizing bi-directional tunneling to employ features of multi-homing. Ng & Tanaka Expires - August 2003 [Page 5] Internet-Draft Multi-homing Issues in NEMO February 2003 2. Multi-Homing in NEMO 2.1. Deployment Scenarios of Multi-homed NEMO 2.1.1. Single Mobile Router with Multiple Egress Interfaces Bound to a Single Home Agent First type of multi-homed mobile network contains only one mobile router. This mobile router have a plurality of egress interfaces, all of which bounds to the same home agent. In such cases, the mobile router usually only advertise a single network prefix to the mobile network. This is illustrated in Figure 2.1 below. +-------------------------+ | | Binding Cache | | | HoA CoA | | | 1::1 2::1 | | Home | 1::2 3::1 | | Agent |=================| | | Routing Table | | | Dest Next-Hop | | | 1:1::/96 1::1 | +-------------------------+ | | +-------------------------------------+ | | | Internet | | | +-------------------------------------+ | | Interface 1 | | Interface 2 CoA=2::1 | | CoA=3::1 HoA=1::1 | | HoA=1::2 | | +--------------------+ | Mobile Router | +--------------------+ | prefix=1:1::/96 ----------------?---------------- | +----------------+ | Mobile Network | address=1:1::x | Node x | +----------------+ Figure 2.1 - Single MR with Multiple Egress Interfaces to a Single Home Agent. Ng & Tanaka Expires - August 2003 [Page 6] Internet-Draft Multi-homing Issues in NEMO February 2003 One example of this type of deployment scenario is that a single Internet Service Provider (ISP) offers two different wireless public access methods such as IEEE 802.11 and GPRS. A mobile router with both access interfaces (i.e. 802.11 and GPRS capabilities) may subscribe to the same ISP and is allowed to use both access methods. The ISP will choose to provide a single home agent for the same mobile router for ease of management. 2.1.2. Single Mobile Router with Multiple Egress Interfaces Bound to Different Home Agents The second type of multi-homed mobile network involves a single mobile router with more than one egress interfaces. Each of these egress interfaces is bound to different home agents. This is illustrated in Figure 2.2 below. The mobile router can advertise a single network prefix and inject the appropriate routing update to the home agents (not shown in the figure). In this case, the mobile router uses only one interface for bi-directional tunneling. Alternatively, the mobile router could also advertise two different network prefixes (as shown in the figure). Both egress interfaces are then utilized, and the mobile router maintains two active bi- directional tunnels with both home agents. Example of this kind of deployment scenarios is when a mobile router subscribes to different ISPs. For instance, it may subscribe to 802.11 public access services using one ISP, and subscribe to GPRS services from another ISP. In this case, the two different ISPs will provide two different home agents for the same mobile router. Ng & Tanaka Expires - August 2003 [Page 7] Internet-Draft Multi-homing Issues in NEMO February 2003 +-------------------------+ +-------------------------+ | Binding Cache | | | | Binding Cache | | HoA CoA | | | | HoA CoA | | 1::1 3::1 | Home | | Home | 2::1 4::1 | |=================| Agent | | Agent |=================| | Routing Table | 1 | | 2 | Routing Table | | Dest Next-Hop | | | | Dest Next-Hop | | 1:1::/96 1::1 | | | | 2:1::/96 2::1 | +-------------------------+ +-------------------------+ | | | | +-------------------------------------+ | | | Internet | | | +-------------------------------------+ | | Interface 1 | | Interface 2 CoA=3::1 | | CoA=4::1 HoA=1::1 | | HoA=2::1 | | +--------------------+ | Mobile Router | +--------------------+ | prefix=1:1::/96, 2:1::/96 ----------------?---------------- | +----------------+ | Mobile Network | address=1:1::x | Node x | or 2:1::x +----------------+ Figure 2.2 - Single MR with Multiple Egress Interfaces to Different Home Agents. 2.1.3. Multiple Mobile Routers The third type of multi-homed mobile network involves multiple mobile routers on the same mobile network. Each of these mobile routers advertise an egress route to the global Internet. In such cases, two different network prefixes are advertised to the mobile network nodes. This is illustrated in Figure 2.3 below. Example of this kind of deployment scenarios is when a mobile network contains more than one device with independent routes to the global Internet. An excellent illustration is the Wireless Personal Area Network (W-PAN) where a mobile phone on the W-PAN connects to the Ng & Tanaka Expires - August 2003 [Page 8] Internet-Draft Multi-homing Issues in NEMO February 2003 Internet via GPRS services, and a Personal Digital Assistant (PDA) on the same W-PAN connects to the Internet via 802.11 public access. +-------------------------+ +-------------------------+ | Binding Cache | | | | Binding Cache | | HoA CoA | | | | HoA CoA | | 1::1 3::1 | Home | | Home | 2::1 4::1 | |=================| Agent | | Agent |=================| | Routing Table | 1 | | 2 | Routing Table | | Dest Next-Hop | | | | Dest Next-Hop | | 1:1::/96 1::1 | | | | 2:1::/96 2::1 | +-------------------------+ +-------------------------+ | | | | +-------------------------------------+ | | | Internet | | | +-------------------------------------+ | | CoA=3::1 | | CoA=4::1 HoA=1::1 | | HoA=2::1 | | +----------+ +----------+ | Mobile | | Mobile | | Router 1 | | Router 2 | +----------+ +----------+ prefix=1:1::/96 | | prefix=2:1::/96 -------?--------?--------?------- | +----------------+ | Mobile Network | address=1:1::x | Node x | or 2:1::x +----------------+ Figure 2.3 - Multiple MRs on the Same Mobile Network. 2.2. Issues of Multi-Homing in NEMO When a mobile network is multi-homed, mobile network nodes can choose to use different routes to send packets to the global Internet, either by way of using different global addresses, or by forwarding the packets to different routers. However, with bi-directional tunneling mechanism employed by mobile routers, mobile network nodes only chose one mobile router as their default router. When this mobile router loses its connection to the global Internet, it can no longer maintain a tunnel with its home Ng & Tanaka Expires - August 2003 [Page 9] Internet-Draft Multi-homing Issues in NEMO February 2003 agent. Thus all mobile network nodes that made use of the mobile router will lose their connectivity to the global network as well. This is hardly desirable, since there may exits another mobile router on the same network that has an active link to the global Internet. Mobile network nodes may eventually realize that their default router no longer has a route to the global network, and select an alternate mobile router as their default router. Such a scheme relies on the mobile network nodes to perform their own route discovery. It adds processing load to mobile network nodes, which may have very limited processing powers (e.g. embedded devices), and incurs additional delays (for the mobile network nodes to realize their current default route is down). In addition, different mobile routers will advertise different subnet prefixes, and thus when mobile nodes eventually switch their default routers, they will have to use different care- of-addresses. This requires sending of binding updates to their home-agents, further increasing the lag of recovery. Ng & Tanaka Expires - August 2003 [Page 10] Internet-Draft Multi-homing Issues in NEMO February 2003 3. Using Multi-Homing Features in Bi-Directional Tunnels In order to utilize the additional robustness provided by multi- homing, mobile routers that employ bi-directional tunneling with their home agents should dynamically change their tunnel exit points depending on the link status. For instance, if a mobile router detects that one of its egress interface is down, it should detect if any other alternate route to the global Internet exists. This alternate route may be provided by any other mobile routers connected to one of its ingress interfaces that has an independent route to the global Internet, or by another active egress interface the mobile router it self possess. If such an alternate route exists, the mobile router should re-establish the bi-directional tunnel using this alternate route. In the remaining part of this section, we will attempt to investigate methods of performing such re-establishment of bi-directional tunnels. It is not the objective of this memo to specify a new protocol specifically tailored to provide this form of re- establishments. Instead, we will limit ourselves to currently available mechanisms specified in Mobile IPv6 and Neighbour Discovery in IPv6 [19]. 3.1. Detecting Presence of Alternate Routes To actively utilize the robustness provided by multi-homing, a mobile router must first be capable of detecting alternate routes. This can be manually configured into the mobile router by the administrators if the configuration of the mobile network is relatively static. It is however highly desirable for mobile routers to be able to discover alternate routes automatically for greater flexibility. The case where a mobile router possesses multiple egress interface (bound to the same home agent or otherwise) should be trivial, since the mobile router should be able to "realize" it has multiple routes to the global Internet. In the case where multiple mobile routers are on the mobile network, each mobile router has to detect the presence of other mobile router. A mobile router can do so by listening for Router Advertisement message on its *ingress* interfaces. When a mobile router receives a Router Advertisement message with a non-zero Router Lifetime field from one of its ingress interfaces, it knows that another mobile router which can provide an alternate route to the global Internet is present in the mobile network. Ng & Tanaka Expires - August 2003 [Page 11] Internet-Draft Multi-homing Issues in NEMO February 2003 3.2. Re-Establishment of Bi-Directional Tunnels When a mobile router detects that the link be which its current bi- directional tunnel with its home agent is using is down, it needs to re-establish the bi-directional tunnel using an alternate route detected. We consider two separate cases here: firstly, the alternate route is provided by another egress interface that belongs to the mobile router; secondly, the alternate route is provided by another mobile router connected to the mobile network. We refer to the former case as an alternate route provided by an alternate egress interface, and the latter case as an alternate route provided by an alternate mobile router. 3.2.1. Using Alternate Egress Interface When an egress interface of a mobile router loses the connection to the global Internet, the mobile router can make use of its alternate egress interface should it possess multiple egress interfaces. The most direct way to do so is for the mobile router to send a binding update to the home agent of the failed interface using the care-of- address assigned to the alternate interface in order to re-establish the bi-directional tunneling using the care-of-address on the alternate egress interface. After a successful binding update, the mobile router encapsulates outgoing packets through the bi- directional tunnel using the alternate egress interface. The idea is to use the global address (most likely a care-of-address) assigned to an alternate egress interface as the new (back-up) care- of-address of the mobile router to re-establish the bi-directional tunneling with its home agent. 3.2.2. Using Alternate Mobile Router When the mobile router loses a connection to the global Internet, the mobile router can utilize a route provided by an alternate mobile router (if one exists) to re-establish the bi-directional tunnel with its home agent. First, the mobile router has to obtain a care-of- address from the alternate mobile router (i.e. attaches itself to the alternate mobile router). Next, it sends binding update to its home agent using the care-of-address obtained from the alternate mobile router From then on, the mobile router can encapsulates outgoing packets through the bi-directional tunnel using via the alternate mobile router. The idea is to obtain a care-of-address from the alternate mobile router and use this as the new (back-up) care-of-address of the mobile router to re-establish the bi-directional tunneling with its home agent. Ng & Tanaka Expires - August 2003 [Page 12] Internet-Draft Multi-homing Issues in NEMO February 2003 Note that every packet sent from/to mobile network nodes to/from their correspondent nodes will experience two levels of encapsulation. First level of tunneling is done between a mobile router which the mobile network node uses as its default router and the mobile router's home agent. The second level of tunneling is done between the alternate mobile router and its home agent. 3.3. To Avoid Tunneling Loop The method of re-establishing the bi-directional tunnel as described in Section 3.2 may lead to infinite loops of tunneling. This happens when two mobile routers on a mobile network lose connection to the global Internet at the same time and each mobile router tries to re- establish bi-directional tunnel using the other mobile router. We refer to this phenomenon as tunneling loop. One approach to avoid tunneling loop is for a mobile router that has lost connection to the global Internet to insert an option into the Router Advertisement message it broadcasts periodically. This option serves to notify other mobile routers on the link that the sender no longer provides global connection. Note that setting a zero Router Lifetime field will not work well since it will cause mobile network nodes that are attached to the mobile router to stop using the mobile router as an access router too (in which case, things are back to square one). 3.4. Other Considerations When a mobile network is multi-homed, mobile network nodes may receive Router Advertisements that advertise different network prefixes. This is usually the case when the multi-homed mobile network has two or more mobile routers advertising different routes to the global Internet. It may also occur when the mobile network has only one mobile router with multiple egress interfaces bound to different home agents. In these situations, mobile network nodes typically only select one to form its global (possibly care-of) address. In view of this, it may be desirable for mobile network node to be able to acquire "preference" information on each mobile network prefix from the mobile routers. This allows default address selection mechanism such as that specified in [20] to be used. Further exploration on setting such "preference" information in Router Advertisement based on performance of the bi-directional tunnel might prove to be useful. Ng & Tanaka Expires - August 2003 [Page 13] Internet-Draft Multi-homing Issues in NEMO February 2003 4. Security Considerations Currently the following security threat is identified with multi- homing in NEMO: - A malicious node in a mobile network advertises an Router Advertisement message with a non-zero Router Lifetime field, tricking mobile network nodes and even mobile routers to forward all packets through it. This is not specific to the multi-homing approach described in this document. However, an authentication mechanism that can authenticate a mobile router from mobile network node when it attaches may be able to prevent such attacks. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [3] Soliman, H., and Pettersson, M., "Mobile Networks (MONET) Problem Statement and Scope", Internet Draft, draft-soliman- monet-statement-00.txt, Work In Progress, Feb 2002. [4] Ernst, T. et. al., "Network Mobility Support Requirements", Internet Draft, draft-ietf-nemo-requirements-00.txt, Work In Progress, Feb 2003. [5] Lach, H. et. al., "Mobile Networks Scenarios, Scope and Requirements", Internet Draft, draft-lach-monet-requirements- 00.txt, Work In Progress, Feb 2002. [6] Kniventon, T. J., and Yegin, A. E., "Problem Scope and Requirements for Mobile Networks Working Group", Internet Draft, draft-kniventon-monet-requiremetns-00.txt, Work In Progress, Feb 2002. [7] Perkins, C. E. et. al., "IP Mobility Support", IETF RCF 2002, Oct 1996. [8] DARPA, "Internet Protocol", IETF RFC 791, Sep 1981. Ng & Tanaka Expires - August 2003 [Page 14] Internet-Draft Multi-homing Issues in NEMO February 2003 [9] Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility Support in IPv6", Internet Draft: draft-ietf-mobileip-ipv6- 19.txt, Work In Progress, Oct 2002. [10] Deering, S., and Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification", IETF RFC 2460, Dec 1998. [11] Simpson, W., "IP in IP Tunneling", IETF RFC 1853, Oct 1995. [12] Conta, A., and Deering, S., "Generic Packet Tunneling in IPv6", IETF RFC 2473, Dec 1998. [13] Kniveton, T. et. al., "Mobile Router Tunneling Protocol", Internet Draft: draft-kniveton-mobrtr-03.txt, Work In Progress, Nov 2002. [14] Petrescu, A., et. al., "Issues in Designing Mobile IPv6 Network Mobility with the MR-HA Bidirectional Tunnel (MRHA)", Internet- Draft: draft-petrescu-nemo-mrha-00.txt, Work In Progress, Oct 2002. [15] Thubert, P., and Molteni, M., "IPv6 Reverse Routing Header and Its Application to Mobile Networks", Internet Draft: draft- thubert-nemo-reverse-routing-header-01.txt, Work In Progress, Oct 2002. [16] Ernst, T., Castelluccia, C., Bellier, L., Lach, H., and Olivereau, A., "Mobile Networks Support in Mobile IPv6 (Prefix Scope Binding Updates)", Internet Draft: draft-ernst-mobileip- v6-network-03.txt, Work In Progress, Mar 2002. [17] Ng, C. W., and Takeshi, T., "Securing Nested Tunnels Optimization with Access Router Option", Internet Draft: draft- ng-nemo-access-router-option-00.txt, Work In Progress, Oct 2002. [18] Ernst, T., and Lach, H., "Network Mobility Support Terminology", Internet Draft, draft-ernst-nemo-terminology- 00.txt, Work In Progress, Oct 2002. [19] Narten, T., Nordmark, E., and Simpson, W., "Neighbour Discovery for IPv6", IETF RFC 2461, Dec 1998. [20] Draves, R., "Default Address Selection for IPv6", draft-ietf- ipv6-default-addr-select-09.txt, Work in progress. Ng & Tanaka Expires - August 2003 [Page 15] Internet-Draft Multi-homing Issues in NEMO February 2003 Author's Addresses Chan-Wah Ng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #04-3530 Tai Seng Industrial Estate Singapore 534415 Phone: (+65) 6554 5420 Email: cwng@psl.com.sg Takeshi Tanaka R&D center Panasonic Mobile Communications Co., Ltd. 5-3, Hikarinooka, Yokoshuka-shi, Kanagawa 239-0847, Japan Phone: +81-46-840-5494 Email: Takeshi.Tanaka@yrp.mci.mei.co.jp Ng & Tanaka Expires - August 2003 [Page 16]