Handling Addressing and Mobility in Hybrid Wireless Mesh Networks TIK Report 250. Abstract

Transcription

1 Handling Addressing and Mobility in Hybrid Wireless Mesh Networks TIK Report 250 Olga Bondareva, Rainer Baumann Computer Engineering and Networks Laboratory Swiss Federal Institute of Technology ETH-Zentrum, Switzerland Abstract To participate in communication, a network node requires an address. In wired computer networks a node receives its address according to the hierarchical context. In contrast to wired networks, Wireless Mesh Networks have flat topology, since nodes are free to move and create highly changeable context. Besides, Wireless Mesh Networks should support mobility of nodes. By merging of hierarchical wired networks and flat wireless networks in Hybrid Wireless Mesh Networks, an address allocation scheme should meet the demands of both wired and wireless domains, and moreover, mobility support should be introduced. In this report we define the problem of address allocation and mobility support in Hybrid Wireless Mesh Networks. We review and evaluate the solutions presented in the literature and also analyze the problem of mobility detection more closely. 1 Introduction Address allocation is necessary to enable packet exchange between networks nodes. Traditional wired IP networks have hierarchical address space, where an address not only identifies a node in the network, but also enables location of a node in the hierarchical topology. The purpose of address allocation schemes in hierarchical wired networks is to assign every node a unique and topologically correct identifier. In contrast to fixed wired IP networks, Wireless Mesh Networks (WMNs) are selfconfiguring networks consisting of mobile nodes interconnected by wireless links. WMNs by nature have flat and changing topology, since mobile nodes are free to move. In standalone WMNs with flat address space, address only identifies a node within the network. Furthermore, since nodes in WMN are mobile, mobility should be supported. Thus, the purpose of address allocation schemes is to assign every node a unique identifier within a WMN disregarding topological correctness, but mobility should be considered. The problem of addressing and mobility support arises when a WMN with flat addresses connects to the Internet. In this case, mobility should be supported and it is desirable to keep the same address when a node moves. However, to support hierarchical routing, addresses should meet the requirements of the wired domain, i.e. topologically correspond to current location of a node. In this report we focus on address allocation in Hybrid Wireless Mesh Networks (HWMNs), which are interconnected to hierarchical IP based networks. An address allocation scheme for a HWMN should support global IP connectivity, assign topologically correct addresses and in addition let a node be mobile and move between

2 different HWMNs. There are several works concerning address allocation and mobility support in HWMNs. In this report we give an overview and evaluate existing methods providing address allocation and mobility support. We also make a detailed analysis of mobility detection problem and propose solutions for the area not covered by previous researches. Without restrictions, we suppose that routing in a WMN is performed by means of an ad-hoc routing protocol fitted for a particular WMN (for example, pro-active: DSDV [40], OLSR [41]; or reactive: AODV [38], DSR [42]). The rest of this report is structured as follows: section 2 presents problem statement; section 3 gives a review of existing methods of address allocation and mobility support; in section 4 we evaluate methods presented in section 3; in section 5 we perform detailed analysis of mobility detection in HWMNs; section 6 concludes the report.

3 2 Problem statement In this section we present different scenarios of interconnection between the wireless and the wired domain and display problems for address allocation corresponding to these scenarios. In IP-based networks nodes have hierarchically structured IPv4 or IPv6 addresses. IP addresses are used to identify nodes and to support hierarchical routing. In WMNs, mobile nodes connect to a wired IP network through gateways. The gateways have interfaces in both wireless and wired domains. We suppose that gateways never switch off, have unlimited power and fixed location. We define 4 scenarios with increasing complexity for address allocation in HWMNs. Scenario 1: In the simplest scenario as Figure 1 illustrates, there is only one gateway and every mobile node from the wireless domain that needs internet connection should have direct access to the gateway, that is one-hop routing. Address allocation for a WMN with only one gateway represents no difficulties and is similar to address allocation in a subnet of a fixed IP network. A WMN in this scenario is considered as one sub-network as in [8, 17]. Consequently address allocation scheme should assign every node a unique address and ensure topological correctness of assigned addresses. That is, all nodes in a HWMN should have the same network prefix as the gateway they use to connect to the Internet. Scenario 2: In [8, 24, 14] multi-hop ad-hoc routing protocols increase range of gateways allowing every node in WMN to reach a gateway. Figure 2 illustrates the case, when one gateway in WMN is connected to the Internet and all other nodes can access Internet from this gateway. In this case address allocation is also similar to address allocation in a subnet of a fixed IP network and requires assignment of a unique and topologically correct address to every node. Scenario 3: In large WMNs using multi-hop routing there can be multiple gateways. As a result, nodes can connect to the closest gateway and gain transmission speed as Figure 3 illustrates. Moreover, the load on a single gateway can be reduced. Although different gateways have different IP addresses, a WMN has one point of attachment to the IP network. In this situation we deal with micro mobility, when node movements are restricted by the same access network. Address allocation in this case additionally requires support of multiple gateways and support of open transport connections, while switching to another gateway. Scenario 4: Figure 4 presents a case, where a WMN is intersecting different access networks employing multi-hop routing and multiple gateways. A mobile node in such WMN wishes to connect to the nearest Access Network and needs to maintain established connection to the Internet also when it moves to the area of other Access Networks. This macro mobility, when a node moves between different access networks, creates extra complexity for address allocation schemes. To enable routing in fixed IP-based networks IP addresses assigned to nodes should be topologically correct. However, different access networks have different points of connection to IP network and if a mobile node changes its IP address when switching to a new access

4 WMN, existing TCP connections will break, which is objectionable. In addition to global connectivity and topological correctness, in this scenario address allocation scheme should be able support mobility. Figure 1 Scenario 1: WMN with a single gateway: only one-hop neighbors are connected to the Internet Gateway Figure 2 Scenario 2: Gateway service spans over multihop WMN. Figure 3 Scenario 3: WMN with multiple gateways Figure 4 Scenario 4: WMN intersecting multiple access networks To be explicit, we should also mention multihoming. Multihoming refers to a situation when a host has two or more simultaneous connections in different access networks. Host multihoming usually results from a host having several interfaces in different networks. Thus, each interface can be considered separately. Consequently, multihoming is not an addressing issue and should be supported by routing protocol and applications.

5 From the presented scenarios we can define following stringent criteria for a method providing address allocation and mobility support in HWMN: 1. Support of global IP connectivity; 2. Topological correctness of an allocated address; 3. Support of multiple gateways; 4. Mobility support; 5. Support of open transport connections after switching to another network or a gateway. Additionally we also consider soft criteria for an address allocation scheme. It is desirable that an addressing scheme: 1. is scalable in terms of nodes per gateway; 2. is compatible with existing Internet infrastructure; 3. lets a node act as a server; 4. does not create additional overhead; 5. does not require external service point.

6 3 Proposed Methods In this section we present existing solutions to address allocation problem in HWMNs. We can define two tasks of an address allocation scheme: first, it is necessary to assign every node a unique local address and, second, to maintain global connectivity of a node in case of mobility. We give an overview of address assignment methods in subsection 3.1 and describe methods to maintain global connectivity in subsection Address assignment For an address allocation scheme it is important first to assign every node a unique local address. To assign unique addresses for nodes inside a WMN, following approaches can be employed: Stateless for stateless address allocation there is no centralized mechanism to assign addresses and nodes configure unique addresses automatically. In the literature three possibilities for stateless address allocation are proposed: - In [4, 25, 24, 19] it is suggested that a node first generates its address randomly (from range 2048 (2 32-n -1) where n is the number of significant bits in the advertised prefix) and then checks its uniqueness using Duplicate Address Detection (DAD) Protocol [25] 1. - In [28, 21] it is suggested to use IPv6 automatic address configuration together with One-hope [32] or Weak DAD [29] 2. - It is also possible to assign a globally unique address to every mobile node under IPv6 as suggested in [5]. To obtain an address routable in the Internet, a node can then use a network prefix that is periodically advertised by the gateway or send a request to the gateway [24] or a prefix can be added to packets at a gateway. Some WMN proposals suggest a hierarchical network scheme [8, 18, 6, 11, 13], while other use flat address space. To cope with address duplication by networks merging [16, 29] suggest relying on routing protocols. Stateful in stateful approach a centralized mechanism is used to assign unique addresses, such as DHCP server or a Foreign Agent in Mobile IPv4. To adapt DHCP allocation mechanism to wireless multi-hop networks [18] suggests that a new node first requests DHCP server for an address; then each node runs DHCP daemon allowing new nodes to connect to DHCP server. 3.2 Maintenance of global connectivity in case of mobility In this subsection we present methods that enable global IP connectivity. We give an overview of following methods proposed in the literature: Mobile IP, Network Address Translation (NAT), Host Identity Protocol (HIP) and cellular addressing scheme. 1 DAD is the process by which a node, which lacks an IP address, determines whether a candidate address it has selected is available. A node already equipped with an IP address participates in DAD in order to protect its IP address from being accidentally misappropriated for use by another node. The uniqueness check is based on sending an Address Request (AREQ) and expecting an Address Reply (AREP) back in case the address is not unique. In case no AREP is received, the uniqueness check is passed. 2 WeakDAD proposal allows the coexistence of duplicate addresses in MANET instead of resolving the conflict with some DAD messages immediately

7 3.2.1 Mobile IP Mobile IP [23, 7] is a protocol designed by the Internet Engineering Task Force (IETF) to enable mobile nodes to move between different access networks and keep its permanent IP address. In Mobile IP a node has two addresses - a permanent home address and a care-of address, which is associated with the access WMN the mobile node is using. There are two kinds of entities in Mobile IP: - A Foreign Agent advertises care-of addresses, which are used by Mobile IP and stores information about mobile nodes visiting its network. Mobile nodes register at a Foreign Agent and use the network prefix of this Foreign Agent to generate a care-of-address. - A Home Agent is located in the home network of a mobile node and stores information about mobile nodes. Figure 5 illustrates communication using Mobile IP protocol. First, an initiating Correspondent Host uses the Home Address of the Mobile Node to send packets. These packets are tunneled by the Home Agent to the Mobile Node's care-of address with a new IP header, preserving the original IP header. At the end of the tunnel the packets are decapsulated and the added IP header is removed. Then packets are delivered to the mobile node. If a Mobile Node moves to another Foreign Agent, it should notify Home Agent about new care-of address. Figure 5 Mobile IP The original version of Mobile IP was designed for Mobile IPv4. This version evolved in Mobile IPv6, where following important improvements have been made. As in IPv6 nodes are able to auto configure topologically correct IPv6 addresses, there is no need in Foreign Agents. To avoid triangle routing it is suggested that the Mobile Node informs the Corresponding Host of its care-of-address by sending binding updates. Then the Corresponding Host sends packets directly to care-of-address of Mobile Host. It is also assumed that Mobile Host notifies Corresponding Host, when it changes location. To enable use of Mobile IP in WMNs Mobile IP was combined with multi-hop adhoc routing in [24, 14, 31, 8, 30, 26]. If there are multiple gateways in the network, hop count [14, 24] or Euclidean distance and load [2, 3] are used as criteria to switch to another gateway. To enable multiple gateways serve a node simultaneously as in scenario 3, [1] suggests exchanging list of visiting nodes between gateways, whereas all hosts

8 homed in the ad hoc network should have the same network prefix. A Home Agent then chooses the best care-of-address assuming round trip time. Mobile IP can support multiple gateways and mobility of nodes; it also maintains open sessions of transport level. Thus, Mobile IP is suitable for scenarios 1 4. However, we can define following drawbacks of Mobile IP: - In mobile IP nodes have to report every change of their access point to their home network, which may create a lot of overhead and introduce large delays, when a mobile node often switches to a new network. - Every visiting node should have a globally routable Home Address and Home Agent should be reachable Network Address Translation Network Address Translation (NAT) [27] translates the source IP address of outgoing packets from the WMN node. In CISCO terminology a node using a NAT has 2 addresses: - inside local address: refers to an IP address assigned to a host inside the private network; - inside global address: refers to an address which represents a host in the outside network. A NAT replaces the inside local IP address with an inside global address of the NAT gateway, which is routable in the external network (see Figure 6). Thus, an external host returns packets using the IP address of the NAT as destination IP address. The NAT can then replace the destination IP address with the inside local IP address of the mobile node, and inject the return traffic into the WMN. Figure 6 Network Address Translator: replaces the inside local IP address with an inside global address of the NAT gateway In WMN with multiple gateways (see Figure 4) a NAT can be placed at every gateway or at the point of attachment to the IP network on a network router. The case with only one NAT on the central router (see Figure 7) represents no difficulties for sessions between nodes located in different access network, but requires extra support is required for session when both nodes are mobile and are located in the same access network [37].

9 Figure 7 A NAT is allocated on the network router However, if NAT is implemented at every gateway, then due to address translation packets sent by the same mobile node through different gateways will have different source IP addresses, which will cause TCP sessions to break. To enable multiple NATbased gateways it is proposed to use explicit tunneling [10, 9], as Figure 8 illustrates. That is, instead of using the default route, the mobile node simply tunnels the IP packets (by IP-in-IP encapsulation or minimal IP encapsulation [22]), to the IP address of the NATgateway. However, gateways must be able to accept and decapsulate tunneled packets. Before sending the first packet to the external host, the mobile node chooses an appropriate gateway. The mobile node consequently uses the same gateway for subsequent packets belonging to the same communication session, as long as it has a route to the gateway. Figure 8 NAT at each gateway; explicit tunneling is required. Another solution supporting multiple NAT based gateways and macromobility presented in [37] implies use of two IP addresses and tunneling between Home and Visited NAT, which is similar to the Mobile IPv4. To sum up, employing NAT is efficient for scenarios 1 3, when a NAT is located on central router, since in this scenarios macromobility support is not required an a node

10 does not need to have fixed Home Address or register at a gateway. However, employing NAT at every gateway or supporting macromobility requires tunneling and creates large overhead. Therefore NAT can not be used in scenario 4. In addition we define following drawbacks of NAT in HWMNs: - NAT provides no support for internetwork mobility a mobile node needs to be connected to the same NAT gateway to keep current TCP session or a tunnel between the Home and the Visited NAT is required. - Cooperation with mobile IP requires additional mechanisms, such as NAT traversal over NAT based gateways [15] and creates large overhead Host Identity Protocol Host Identity Protocol (HIP) [34, 35] provides a method of separating the end-point identifier and locator roles of IP addresses. HIP introduces a new Host Identity (HI) name space between the transport and network layers (see Figure 9 a), b)). In the HIP packet exchange a unique HI name is used to identify nodes and establish and update HIP associations between nodes. a) b) Figure 9 HIP a) new layer; b) resolution. A mobile node usually establishes the initial contact with a Correspondent Host by resolving the locators and the identifiers of the Correspondent Host from the DNS. However, the DNS may not be always up-to-date with the changes in the locators of the Correspondent Host because the Correspondent Host may also be mobile. The Secure Domain Name System (DNS) Dynamic Update [33] is a better alternative, but even it is hindered by DNS caching. The HIP alleviates the problems related to the DNS. With HIP rendezvous extensions, a HIP node can be reached via the IP address of a third party, the node's Rendezvous Server. The Rendezvous Server is reachable by a set of stable locators. With HIP, the DNS configuration for a node consists of the endpoint identifiers (HIs) of the node and the stable locators of the Rendezvous Server. Now, when a node initiates a connection to the Correspondent Host using the information gathered from the DNS, the first HIP signaling message is routed to the Rendezvous Server instead of the Correspondent Host (see Figure 10). The Rendezvous Server forwards the packets to the current location of the Correspondent Node. The rest of the HIP messages are carried directly between the end-nodes to avoid triangular routing. When the mobile node changes its location, it

11 informs the rendezvous server and Correspondent Host of the new locators. As the Rendezvous Server does not change its location, both the mobile and corresponding node always knows how to contact it. The rendezvous server resembles the home agent in the Mobile IP architecture. Figure 10 Establishment of a HIP association. HIP enables end-to-end IP mobility transparent to the transport layer. Thus, HIP is a solution for scenarios 1 4. Nevertheless we should consider one flaw: - HIP deployment will require modifications to the existing networking stacks and introduction of the global rendezvous service Cellular addressing scheme Another solution to addressing issue in WMN we should mention is already implemented in existing systems of cell stations for mobile phones, which keep the list of all nodes in range and provide roaming for visiting nodes by transmitting a list of visiting nodes to the home network of a visiting node. Every mobile node has globally unique number of a sim card. In [12] a performance comparison of cellular and wireless networks has been presented. It is concluded that existing wireless networks perform better in terms of throughput, delay and power, but suffer from unfairness and poor performance in event of mobility. This solution could be employed for scenarios 1 4. However, this solution is expensive and creates large load for base stations.

12 4 Evaluation In this section we evaluate methods to maintain global connectivity in case of mobility presented in section 3. Based on scenarios from section 2, we developed stringent criteria; we also consider a list of soft criteria. Considering these criteria, we analyze the most promising methods to maintain global connectivity. In this section we first present stringent and soft criteria. Then we apply these criteria to evaluate Mobile IP, NAT and HIP. Stringent criteria: 1. Support of global IP connectivity a node is able to connect to the Internet and to be reachable from the Internet; 2. Topological correctness of an allocated address all nodes in a HWMN have the same network prefix as the gateway they use to connect to the Internet; 3. Support of multiple gateways a node is able to connect to the closest gateway in the network and to switch between the gateways while moving; 4. Mobility support a node is able to move between different access networks keeping its connection to the Internet; 5. Support of open transport connections after switching to another network or a gateway current connection of transport level, such as TCP sessions should remain active during mobility. Soft criteria: No external service point it is desirable that mobile nodes do no require external service points; Compatibility with existing Internet infrastructure proposed approach should not require major changes to the existing infrastructure; Enabling a node act as a server a mobile node should be accessible by other nodes willing to initiate a connection, while moving to another point of attachment; Scalability in terms of nodes per gateway proposed approach should not create large load on gateways; Small additional overhead proposed solution should not cause large additional overhead. Evaluation of Mobile IP, NAT and HIP according to the criteria is presented in Table 1. We mark accordance with a criteria with + and disagreement with. In the column Requested for scenario X we mark with # stringent criteria which are required for a specific scenario. From Table 1 we can summarize that NAT is suitable for scenarios 1 and 2. Moreover, locating a NAT on a network router provides simple solution for scenario 3, since in this case all soft criteria are fulfilled. Mobile IP and HIP meet stringent criteria for scenario 3 and 4 and both require an external service point for a mobile node. But in contrast to HIP, Mobile IP is compatible with existing Internet infrastructure. Thus, further we will consider HIP and Mobile IP and as solutions for scenario 4.

13 Table 1 Evaluation of methods to maintain global connectivity Mobile IP NAT HIP Required for scenario Stringent criteria: Global IP Connectivity # # # # 2. Topological correctness # # # # 3. Support of multiple gateways + +/ 1 + # # 4. Mobility support + + # 5. Support of open transport connections + + # Soft criteria: No external service point + Compatibility with existing Internet + + infrastructure Enabling a node act as a server Scalability in terms of nodes per gateway + + Small additional overhead + In the rest of this report we consider the problem of mobility detection and discuss possible solutions for this problem with Mobile IP and HIP as underlying technology to maintain global connectivity. 1 Multiple gateways are supported if there is only one NAT located on the network router.

14 5 Detailed analysis of scenario 4 In this section we take a more detailed look at scenario 4 and consider the problem of mobility detection. When a mobile node moves to a new location, it is necessary to detect its mobility and invoke an IP address change. To maintain global connectivity, it is necessary to notify correspondent hosts a node is connected to and other external services. We define two following classes of mobility detection: Class I. A node is aware of macro mobility a) A node knows the gateway it uses: In this case a mobile node controls explicitly which gateway it is connected to. This is the standard case of mobility detection, which is suitable for networks using source routing and some cases of hop-by-hop routing, when a node explicitly knows the path to the gateway it use and handles mobility itself. b) A node is notified by a gateway: When a node is unaware of the uplink path, for example, in case of local repair in hop-by-hop routing, any- or multicast routing, a node will not detect switching to another gateway. Figure 11 illustrates that due to a local repair the Mobile Node loses connection through GW1 and is connected through GW2. In this case gateways should be able to notify new nodes, which are trying to use them. For example, GW2 will receive packets from a new Mobile Node and notify this Mobile Node that it has switched to a new access network WMN B. This will allow any type of routing in the wireless domain. However, a node should be able to handle its mobility. Figure 11 Problem of mobility detection: due to a local repair the Mobile Node loses connection through GW1 and is connected through GW2 Class II. A node is unaware of macro mobility In many cases it is desirable that not only any type routing in the wireless domain is allowed but also that a node doesn t need to handle its mobility. When nodes are not aware of mobility, gateways should control nodes in range and provide connectivity for these nodes. Gateways should be able to handle mobility of these nodes. In this case the control overhead that is created in case of mobility will traverse outside the local network and not load the wireless domain.

15 5.1 Implementation of mobility detection class I In this section we discuss the implementation of mobility detection class I with HIP and Mobile IP as underlying technology. Analyzing methods from section 3, we noticed a gap in mobility detection of class Ib) and II. For these classes we give implementation proposals Implementation of mobility detection class I a) Mobile IP and HIP employ mobility detection only of class Ia), where a node establishes and maintains the default connection to the same gateway. If a default router is no longer reachable, the Mobile Node must discover a new default router (usually on a new link) and if necessary configure a new link local address. In this class of mobility detection the Mobile Node notifies the Correspondent Hosts it is connected to about its current location (see Figure 12). If a node acts as a server a fixed external service point containing current address of the Mobile Node (Home Agent or Rendezvous Server) is required. If a node does not have such service point, the first gateway the node is connected to can take these functions. Figure 12 Mobility detection class Ia): A node controls connection to the gateway. Figure 13 - Mobility detection class Ib): Gateway notifies a node

16 5.1.2 Implementation of mobility detection class I b) In case of any- or multicast routing or local repairs in hop-by-hop routing it is not possible to use mobility detection of class Ia). To provide mobility detection for the class Ib) gateways should be able to notify new nodes, which are trying to use them. To enhance mobility detection of Mobile IPv6 and HIP, we propose that gateways detect new nodes as nodes that use incorrect source addresses (see Figure 13) and inform these nodes. A node handles its mobility and notifies correspondent services of the new path. In this case, even using anycast routing a node will know, which gateway it is connected to. In this class of mobility detection, a node should be aware of its mobility and notify correspondent hosts it is connected to and external service point in case a node acts as a server. 5.2 Implementation of mobility detection class II In this section we present our proposal for implementation of class II mobility detection using Mobile IP and HIP as underlying method. We also discuss the problem of having secure associations between the Mobile Node and the Correspondent Host that arises from using class II of mobility detection. In some cases it is desirable that a node does not need to manage its mobility. Then a mobility detection of class II should be implemented. In Mobile IPv6 and HIP a node should notify Home Agent or Rendezvous Server and Correspondent hosts of its current location. However, these notifications could be done by a gateway. In this case no extra overhead due to mobility load the path from the Mobile Node to the gateway and is carried over to the wired domain. Moreover, any type of routing can be employed between the gateway and the Mobile node in the wireless domain. The routing protocol is out of scope of this report. However, we suppose the routing protocol routs the traffic from a node to one gateway even if this node is in range of several gateways unless the topology of the network changes. For Mobile IP we propose the implementation as illustrated in Figure 14. When the Mobile Node is trying to send packets through a gateway, the gateway notices a new node by a wrong source address (Home Address) and extracts the Home Address from the received packet. Then, the gateway notifies the Home Agent of the new location of the Mobile Node and forwards the packet to the Correspondent Host, substituting the source address by its own address and placing the Home Address of the Mobile Node in the mobile header Home Agent option [36]. On a transport level at the Correspondent Node the source IP address of the gateway is changed by the Home Address of the Mobile Node and vice versa. Thus, on the network level the correspondent host is unaware of actual location of the Mobile Node and the Mobile Node is unaware of its mobility. For Mobile IPv4 it is possible to use UDP encapsulation from the gateway instead of mobile header. The similar solution was proposed for HIP in [39]. It is proposed to use UDP encapsulation of IPv4 packets or alter the IPv6 header for IPv6 traffic. If the Mobile Node moves to a new location a new gateway takes a node under control and notifies the Home Agent or Rendezvous Server and Correspondent Hosts. To deactivate the previously used gateway, we propose to send a notification from the Home Agent or the Rendezvous Server.

17 Figure 14 Mobility detection class II: Gateway controls mobility of a node Security associations In this class of mobility detection the gateway should be trusted by both the Correspondent Host and the Home Agent/Rendezvous Server, since an attack rerouting traffic from Correspondent Host to the false location is possible. To prevent such pseudo route attacks, extra improvements to support secure associations between Mobile and Correspondent Nodes are required. One scenario using Mobile IP as underlying method is illustrated in Figure 15. To enable secure communication between the Mobile Node and the Correspondent Host, tunneling from the gateway to the Home Agent is employed. In this case only the authorization at the Home Agent is required. However, this solution introduce large amount of overhead for tunneling. Figure 15 Mobility detection class II: To support secure associations, packets are tunneled on the path between the gateway and the Home Agent. To support secure associations between the Correspondent Host and the Mobile Node we propose three following scenarios: 1. All packets sent by the Mobile Node are IPSec protected (see Figure 16). In this case the gateway notifies the Home Agent/ Rendezvous Server of the new location of the Mobile Node and only forwards packets from the Mobile Node to the Correspondent Host as described above. The Correspondent Host knows new location of mobile node as soon as it receives packets sent through the new gateway.

18 Figure 16 Support of security in mobility detection class II: all packets are signed. 2. The Correspondent Host request the identification of the Mobile Node after receiving a packet from the Mobile Node sent through an unknown gateway. In this scenario the gateway forwards an unsigned packet to the Corresponding Host and notifies the Home Agent/Rendezvous server (see Figure 17). The Correspondent Host sends an identification request to the Mobile Node after receiving a packet containing the Home Address/HI of the Mobile Node from an unknown gateway. The Mobile Node signs the next packet and continues communication in a normal mode. Figure 17 Support of security in mobility detection class II: A Correspondent Node sends an identification request to the Mobile Node. Figure 18 Support of security in mobility detection class II: The gateway receives the permission to identify the Mobile Node at Home Agent and Correspondent Nodes.

19 3. A gateway receives permission to identify the Mobile Node as a node joins its network (see Figure 18). In this scenario a gateway establishes a trusted association with a new node and obtains a permission to notify the Home Agent/ Rendezvous server and forward packets to Correspondent Nodes. 5.3 Mobility detection: Summary In this section we discussed the problem of mobility detection in Hybrid Wireless Mesh Networks. We defined two classes of mobility detection, which we summarize in Table 2. The class I of mobility detection implies that a node handles its mobility and explicitly knows the gateway it uses. However, this class of mobility detection is not proper in case of any- or multicast routing or local repairs. To solve this problem we proposed to send a notification to a node from the gateway and distinguish subclass Ia) when a node notices its mobility itself and Ib) when a node is notified by a gateway. In the second class of mobility is handled by gateways and a node is unaware of its mobility. Classes Ib) and II are tolerant to the routing method. With class Ia) a node handles its mobility, whereas with class II gateways are loaded with mobility management. Class II is desirable in HWMN, since there is no extra control load on the wireless domain due to mobility, but it is difficult to implement and requires extra modifications to enable secure connections. Class Ib) represents a good solution and is easy to implement using Mobile IPv6 or HIP as underlying technology to support mobility. Handling of Mobility Table 2 Mobility detection and handling: Summary Binding to Gateway Explicit Implicit Node (Class I) Common (Class Ia) Notification? (Class Ib) Gateway (Class II) Not of Interest?

20 Conclusion In this report we analyze the problem of mobility management and address allocation in Wireless Mesh Networks. We have shown that the easiest solution to enable micro-mobility, when a node moves within one access network, is to use a NAT at the border of the access network. MobileIPv6 as well as HIP are the most popular methods to support global IP connectivity of a node in case of macro-mobility of nodes, when nodes move between different access networks. However, these methods require that a node is aware its macromobility. That is, a node knows its global unicast address and explicitly knows through which access network packets are relayed. But this condition is not always fulfilled, e.g. for some cases of hop-by-hop routing, local repair or multi-/anycasting. In this report we defined different classes of mobility detection and proposed two solutions to enable any type of routing in the wireless domain. First, the gateway informs the Mobile Node in case the Node is connected to the new Access network. Second, the gateway handle the mobility of nodes connected though this gateway. The first proposal enables a simple solution to mobility detection problem and can be implemented without major changes to HIP or MobileIPv6. The second proposal is critical with respect to security. We also proposed solutions that ensure security in case the mobility is controlled by the gateways.

21 References 1 C. Ahlund, A. Zaslavsky Integration of Ad hoc Network and IP Network Capabilities for Mobile Hosts. 10 th International Conference on telecommunications (ICT), Feb H. Ammari, H. El-Rewini Using Hyubrid Selection Schemes to Support QoS when Providing Multihop Wireless Internet Access to Mobile Ad Hoc Networks, in Proceedings of the First International Conference on Quality of Service in Heterogeneous Wired/ Wireless Networks (QSHINE 04 ) 3 H. Ammari, H. El-Rewini Integration of Mobile Networks and the Internet Using Mobile Gateways in Proceedings of the 18 th International Parallel and Distributed Processing Symposium (IPDPS 04) 4 G. Andrealis Providing internet access to mobile ad hoc networks. London Communications Symposium, Sep Fleet net as a IPv6 subnet with global fleet net prefix M. Bechler, W.J. Franz, L. Wolf Mobile Internet Access in FleetNet 6 M. Benzaid, P. Minet, K.A. Agha A framework for Integrating Mobile-IP and OLSR Networking for Future Wireless Mobile Systems 7 P. Bhabwat, C.E. Perkins, S.K. Tripathi, Network layer mobility: an architecture and survey, IEEE Personal Communications Magazine 3(3) June J. Broch, D.Maltz, D.Johnson Supporting Hierarchy and Heterogeneous Interfaces in Multi-Hop Wireless Ad Hoc Networks in proceedings of the Workshop on Mobile Computing, June Engelstad, P. and Egeland, G., "NAT-based Internet Connectivity for On Demand MANETs", Proceedings of 1st Wireless On-Demand Networking Symposium 2004 (WONS 2004), Springer-Verlag LNCS Series, P. Engelstad, A. Tonnesen, A. Hafslund, G. Egeland Internet Connectivity for Multi- Homed Proactive Ad Hoc Networks 11 V.D. Hoang, Z. Shao, M. Fujise, H. M. Nguyen A novel Solution for Global Conectivity in MANET 2004 IEEE 12 H. Hung-Yun and R. Sivakumar, Performance Comparison of Cellular and Multi-hop Wireless Networks: A Quantitative Study, in Proceedings of the ACM SIGMETRICS, June R.Hwang, C. Li, C Wang, Y. Chen, mobile Ipv6-Based Ad Hoc Networks: Its Development and Application, IEEE Journal on Selected Areas in Communications vol 23 no 11 November

22 14 U. Jonsson, F. Alriksson, T. Larsson, P. Johansson, G.Q. Maguire Jr., MIPMANET Mobile IP for Mobile Ad Hoc Networks, in MOBIHOC, pp 75-85, August Levkowetz, H. and Vaarala, S., Mobile IP Traversal of Network Address Translation (NAT) Devices. RFC 3519, Internet Engineering Task Force (IETF), April R. Li, X. Ye, J. Shi, J. Sun, H. Wang IP Addressing Auto-Configuration in Global IP Connectivity of Mobile Ad Hoc Networks IEEE J. McGee, M. Karir, J.S. Baras Implementing Ad Hoc to Terrestrial Network Gateways 18 M.J. Miller, W.D. List N.H. Vaidya A Hybrid Network Implementation to Extend Infrastructure Reach tech report A. Nilson, C.E. Perkins, A.J. Tuomien R. Wakikawa, J.T. Malinen AODV and IPv6 Internet access for Ad hoc Networks. 20 E. Nordsrom, P.Gunningberg, C. Tschudin Poster: Comparison of Forwarding Strategies in Internet Connected MANETs 21 I. Park Y. Kim, S. Lee IPv6 Address Allocation in Hybrid Mobile Ad Hoc Networks, Proceedings of the Second IEEE Workshop on Software Technologies for Future Embedded and Ubiquitous Systems (WSTFEUS 04) 22 Perkins, C.E., "IP Encapsulation within IP", RFC 2003, Internet Engineering Task Force (IETF), October C. Perkins IP Mobility Support Request For Comments(standard) 2002, Internet Engeneering Task Force, Oct C.E. Perkins, E.M. Belding Royer, Y. Sun Internet connectivity for ad-hoc mobile networks, International Journal of Wireless Information Networks, April C. E. Perkins, J. T. Malinen, R.Wakikawa, E.M. Belding-Royer, and Y. Sun. IP Address Autoconfiguration for Ad hoc networks. IETF Internet Draft, draft-ietf-manetautoconf-01.txt, November (Work in Progress). 26 P. Ratanchandani, R. Kravets A Hybrid Approach to Internet Connectivity for Mobile Ad Hoc Networks, Proceedings of IEEE WCNC, Srisuresh, P. and Holdrege, M., "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, Internet Engineering Task Force (IETF), August S. Thomson, T. Narten IPv6 Stateless Address Autoconfiguration, Network Working Group RFC 2462, December N. Vaidya, Weak Duplicate Address Detection in Mobile Ad Hoc Networks, MobiHoc 02, June 2002, Lausamme, Switzerland.

23 30 R. Wakikawa, J.T. Malinen, C.E. Perkins, A. Nilson A.J. Tuominen Global connectivity for IPv6 mobile and ad hoc networks, Internet Engineering Task Force, Internet Drafr July B. Xie, A. Kumar Integrated Connectivity Framework for Internet and Ad hoc Networks IEEE International conference on Mobile Ad-hoc and Sensor Systems Y.L. Zhao, R. Shi, X.Z. Yang, One Hop-DAD Based Address Auto-configuration in MANET6, The Fifth International Conference on Parallel and Distributed Computing, Applications and Technologies, Brian Wellington. RFC 3007: Secure Domain Name System (DNS) Dynamic Update. Internet Engineering Task Force, November org/rfc/rfc3007.txt. 34 R.J.W. Wilterdink Host Identity Protocol: A state of the art research D. Johnson, C. Perkins, J. Arkko Mobility Support in IPv6 rfc3775, June M. Buddhikot, A. Hari, K. Singh, S. Miller MobileNAT: A Net Technique for Mobility Across Heterogeneous Address Spaces. 38 C. Perkins, E. Belding-Royer, S. Das Ad-Hoc on Demand Distance vector (AODV) Routing, RFC 3561, July A. Huttunen, B. Swander, V. Volpe, L. DiBurro, M. Stenberg rfc 3948UDP Encapsulation of IPsec ESP Packets, C. E. Perkins and P. Bhagwat, Highly Dynamic Destination-Sequenced Distance- Vector Routing (DSDV) for Mobile Computers, Comp. Commun. Rev., pp , T. Clausen, P. Jacquet, Optimized Link State Routing Protocol, rfc 3626, D.B. Johnson, D.A. Maltz, Dynamic source routing in ad hoc wireless networks, in Mobile Computing, Kluwer Academic Publishers, 1996, vol. 353.