Ohio University

Home , IP header, List of DNS record types, Overhead (computing), Packet loss

DESIGN AND IMPLEMENTATION OF THE MOBILE INTERNET PROTOCOL ON THE LINUX KERNEL TO SUPPORT INTERNET MOBILITY

A Thesis Presented to

The Faculty of the

Fritz J. and Dolores H. Russ College of Engineering and Technology

Ohio University

In Partial Fulfillment

of the Requirement for the Degree

Master of Science

Radha Thothadri

November 1999

OHIO UNIVERSITY

Contents

1 Introduction 1 1.1 Internet Protocol Architecture ...... 3 1.1.1 OSI Model ...... 4 1.1.2 TCP/IP Protocol Suite ...... 5 1.2 Motivation for Mobile IP ...... 8 1.3 Organization of Thesis ...... 9

2 Internet Mobility 10 2.1 Internet Addressing Scheme ...... 10 2.2 Mobility Problem ...... 11 2.3 Mobility Support Requirements ...... 12 2.4 Proposals to Address Internet Mobility Issue ...... 13 2.4.1 Columbia Scheme ...... 13 2.4.2 Sony ...... 14 2.4.3 Loose Source Routing ...... 15 2.5 Overview of Mobile IP ...... 17 2.5.1 Mobile IP Terminology ...... 18 2.5.2 Operation of Mobile IP ...... 19

3 Concepts of Mobile IP Protocol 21 3.1 Agent Discovery ...... 21 3.1.1 Agent Advertisement Message ...... 22 3.1.2 Mobile Host Migration Detection ...... 23 3.1.3 Agent Solicitation Message ...... 23 3.2 Mobile Node Registration ...... 23 3.2.1 Role of the h4obile Host ...... 23 3.2.2 Mobility Agents' Role ...... 24 3.2.3 Registration Message Format ...... 24 3.2.4 Registration Reply from Home Agent ...... 25 3.2.5 Security Concerns for Registration Mechanisms ...... 26 3.3 Routing and Packet Redirection Mechanisms ...... 28 3.3.1 Intercepting Mobile Host Packets ...... 28 3.3.2 Tunneling Packets to Mobile Host ...... 28 3.3.3 Security Concerns for Tunneling ...... 30 3.3.4 Other Security Schemes for Mobile IP ...... 31 3.4 Implementations with a Foreign Agent ...... 32 3.5 Design without Foreign Agent ...... 32

4 Implementation of Mobile IP on Linux 36 4.1 IVhy Linux? ...... 36 4.2 Mobile IP Installation ...... 37 4.2.1 Physical Setup of the Hosts ...... 37 4.2.2 Kernel Modification ...... 37 4.2.3 Kernel Compilation ...... 38 4.3 Mobility Support on the Mobile Host ...... 39 4.3.1 Migration of the Mobile Host ...... 39 4.3.2 Mobile Host Configuration ...... 40 4.3.3 Role of the Mobile Host Daemon ...... 42 4.3.4 Routing Management for Mobile Hosts ...... 45 4.3.5 Summary ...... 49 4.4 Mobility Support on the Home Agent ...... 49 4.4.1 Home Agent Configuration ...... 49 4.4.2 Role of the Home Agent Daemon ...... 50 4.4.3 Summary ...... 53 4.5 Problems and Limitations ...... 54 4.6 Conclusions ...... 55

5 Performance Analysis of Mobile IP Implementation 56 5.1 Description of test-bed ...... 56 5.2 Experiments with ping ...... 57 5.2.1 Observations I ...... 58 5.2.2 Observations I1 ...... 61 5.2.3 Conclusions from the ping Test ...... 62 5.3 Client-Server Program for TCP Packets ...... 63 5.4 Performance Measurements for Routing Optimizations ...... 64 5.5 Performance while Switching Networks ...... 65 5.6 Summary ...... 65

6 Conclusion 66

Bibliography 69

Appendix A 72

Appendix B 75

Appendix C 82 List of Tables

4.1 A sample Mobile Policy Table ...... 47 5.1 Observations of ping requests from Mobile Host ...... 59 5.2 Observations of ping requests from remote hosts to mobile host ... 61 5.3 Observations from the Client-Server Model . The mobile host is the client ...... 64 5.4 Comparison of Bidirectional Tunneling and Triangular Routing ... 65 List of Figures

Overview of Internet ...... 3 OSI reference model ...... 4 TCP/IP suite ...... 7 Addressing scheme in TCP/IP Internet ...... 11 IETF Mobile IP Protocol ...... 19 Mobility Agent Advertisement Message ...... 22 Mobility Node Registration Request Message ...... 25 Mobile IP Tunneling using IP-in-IP ...... 29 Mobile IP protocol without foreign agent ...... 33 Experimental testbed on the ece.ohiou.edu network ...... 37 Representation of mobile host migration ...... 40 A sample file for mobile host configuration ...... 41 A sample file configuration for Mobile Policy Table ...... 41 Triangular routing ...... 46 Bidirectional tunneling ...... 47 Routing with link-layer virtual interface ...... 48 A sample file for home agent configuration ...... 50 Chapter 1

Introduction

Personal computing devices including desktops and workstations are becoming in- creasingly popular with the fall in their prices and the increasing dependence on their computing and organizational capabilities. The spectacular progress in the computer industry over the last few decades, with the continuing revolution in the microproces- sor technology is facilitating the shrink in the physical size of the computing devices to palm tops, notebooks and laptops. These are as powerful, in terms of memory, storage and computing power, as some desktop and workstations.

The proliferation of the powerful portable computers, the increasing availability of wireless network interfaces and products assures users network access at all times. There has been an explosive growth in the Internet, which is a global network connecting various computers, hosts and networks across the world. The Internet that existed in 1990 was barely 5% of the current Internet [Com95, Sur]. The fundamental technology of the Internet has adapted well to the exponential growth and the corresponding increases in the traffic.

With the advent and popularity of online businesses, financial transactions and mar- keting, adopted by every commercial venture, continuous connectivity to the Internet is in great demand. The number of online users has increased from 26 million in 1995 to close to 172 million worldwide as of May, 1999 [Sur]. Thus mobility and portability are essential and crucial in the next generation computers and network protocols. The mobile devices in the existing Internet infrastructure can connect to the Internet using wireless interfaces just as the desktops are connected using Ethernet, token- ring etc. But when the mobile host migrates it changes its point of attachment to the network. This is a change in the network topology. The Internet and the OSI network architecture design is based on the fundamental assumption that the end users are stationary. Thus movement by the end systems leads to loss of existing connection. Replacing the existing Internet protocols to support mobility is infeasible considering the huge investments in the existing infrastructure and the corresponding changes and updates to support over 40 million hosts on the Internet.

The challenge, thus, lies in providing mobility on the Internet with considerations to existing infrastructure, backward compatibility and avoiding excess overhead. In this thesis, we address our implementation of Mobile IP on the Linux platform to support Internet mobility for mobile hosts with a brief outline of the history of the approaches to resolve this mobility issue.

Internetworking technology specifies procedures to accommodate diverse hardware technologies, software architecture and to interconnect heterogeneous networks. The underlying hardware and implementation details of each interconnected physical network is hidden, permitting computers in different networks with diverse architecture to communicate. These individual networks are connected to other networks by devices called routers to constitute a much wider internetwork. These routers have some methods or protocols to communicate the data between the source and destination hosts which could belong to distinct and potentially incompatible networks (see Fig. 1.1).

As a background to the Mobile IP protocol, we will be looking at the Internet protocol architectures and especially the TCP/IP protocol suite and its limitations. This will lead us to the motivation for Mobile IP and its operations. Our implementation on the ece.ohiou.edu subnet will be discussed in detail. Figure 1.1: Overview of Internet

1.1 Internet Protocol Architecture

To minimize the inherent complexity, network protocols are organized as a series of layers or levels. The number and functionality of these layers differ with networks but with the common concept that each layer offers certain services to higher layers hiding the low level implementation details. The rules or conventions that each layer has to conform with, while exchanging information or data with peer entities are collectively termed protocols. Thus a protocol refers to the implementation of service or operations and is hidden from the users and higher layers. The two important network architectures, which standardize protocols and functionality of layers, are the IS0 OSI (Open Systems Interconnection) model and the TCP/IP model. Both these models have the fundamental concept of a stack of independent protocols. 1.1.1 OSI Model

The OSI model is a seven layer model (Fig. 1.2) and specifies what each layer should do. IS0 standards for each layer sets the exact services and protocols at each layer.

{'~eceivini \ t)ATA \\,Process ) - - - - ah.. Name of Unit Exchanged La7r ------[p:;:?' APDU -Presentation ------PPDU 6 i presentation Protocol - - Presentatiod Interface I ! Session 5 : session g&,,i---- 4 SHI DATA /- - - Session i SPDU

Transport TH] DATA /- - - 4-1 TpDU Protocol

3 1: -1~4 DATA 1- - 4 ~etp1 Protocol

DATA - - Bits 1 Bit ! Actual raw data transmission medium Host A Host B

Figure 1.2: OSI reference model

The physical layer is the low-level layer responsible for transmitting raw bits over a communication channel. The design issues deal with mechanical, electrical and procedural interfaces and the physical transmission medium. The Data Link layer provides a well-defined interface to the network layer for data transfer between source and destination machine. It is also responsible for creating frames and reorganiz- ing bits in frames for the physical layer using special bit patterns to mark frame boundaries. Flow regulation between sender and receiver is also a concern of the data link layer. The Network layer deals with routing packets from source to destination, and resolves problems arising due to architectural differences in software or hardware at the source and destination of distinct networks. The network layer thus has to be aware of the network topology. The Transport layer provides reliable, cost-effective data transport from source to destination, independent of the physical networks in use. It enhances the QoS provided at the network layer. The Session layer is to establish "sessions" between users providing enhanced services useful in some applications. It keeps track of dialogue management, token management and synchronization of session. The Presentation layer is concerned with the syntax and semantics of the information transmitted. The Application layer handles the commonly used user-level programs like email, ftp, telnet.

1.1.2 TCP/IP Protocol Suite

With the addition of satellite and radio networks, the protocols based on the OSI architecture had trouble internetworking with them. The ability to connect multiple networks in a seamless way was the major goal stressed in the replacement network architecture. The OSI model was also considered complex with incomprehensible implementation details. Also, addressing, flow control and error control were performed at each layer leading to inefficiency and unnecessary repetition of functions. OSI model does not treat connectionless services and protocol with due importance and the session layer and presentation layer have little utility. Extensive research led to the proposal, adoption and widespread use of the TCP/IP Reference Model.

History and Scope of TCP/IP Internet

The importance and potential of the global Internet prompted extensive research funded by the Advanced Research Projects Agency (ARPA). ARPA was interested in exploring packet-switching network for connectionless communication over radio networks and satellite channels. ARPA internet technology (TCPIIP) includes a set of network standards specifying details of computer communications and a set of rules governing interconnecting networks and traffic. This TCP/IP Protocol Suite is used to communicate across any set of interconnected networks. To popularize TCP/IP and encourage university researchers to adopt the new protocols, ARPA provided a low-cost implementation and funded Berkeley to integrate TCP/IP protocols in its software distribution. Berkeley included a set of network service utilities with UNIX, offering socket abstraction, allowing and encouraging experimentations by researchers.

TCP/IP was announced the only official protocol on January 1: 1983 [Tan96]. With rapid expansion came unanticipated problems which were resolved or managed by extensions to existing protocols or introducing new protocols. To manage scaling problems and host location, Domain Name System (DNS) was developed to map host names on to IP addresses with distributed data among name servers to answer host name queries. Internet naming and addressing and the related mobility problem will be handled in Chapter 2. The protocol stacks of this TCP/IP suite in Fig. 1.3 and their functionality are discussed in the following section.

Internet Protocol Stack

The Application Level contains all the higher-level protocols. From the user's point of view, a TCP/IP internet is a set of application programs that uses the network to handle communication with other end-user systems. Application programs which need network support are disrupted when network connectivity is lost. Widely used application layer programs include Email, remote login, file transfer, DNS. In mobility supported Internet these application programs should work even if the mobile host migrates from its current point of attachment to the Internet.

The Transport layer layer built over the Network layer allows peer entities on source and destination hosts to communicate. This layer has two end-to-end protocols. TCP (Transmission Control Protocol) is a reliable connection-oriented protocol which allows data stream from one machine to be delivered to any machine on the internet without errors. The input stream is fragmented into discrete messages and passes each one onto the internet layer. At the destination the TCP reassembles the fragments into an output stream. TCP also handles flow control so that sender does not swamp the receiver at a rate faster that it can receive.

The UDP(User Datagram Protocol) is an unreliable, connectionless, best effort protocol. It is used by applications either providing their onTnflow control or sequencing or by one-shot, client-server request-reply queries or when prompt delivery is important than accurate delivery like in audio or video transmissions. Host migration should be transparent at this layer and higher layers since it essentially deals with ensuring packet delivery irrespective of end-user networks or capabilities.

Layers Services Protocols Application Services DNS, SMTP, Application programs FTP, HTTP Message I Reliable Transport Services End-to-End communication, TCP, UDP TCP Packet Flow control, QoS Connectionless Packer Delivery Data transfer, Error control, IP, ICMP, IGMP TCP packet routing decision Interfy / 1 IP datagram routing I AW, RAW

Network

Figure 1.3: TCP/IP suite

The Network layer supports packet-switching network. It defines a packet format and the Internet Protocol(1P). This layer delivers IP packets from source to destination in different networks. Packet routing decisions and congestion control are the major issues here. ICMP (Internet Control Message Protocol) and IGMP (Inter- net Group Management Protocol) are the ancillary protocols here. The Mobile IP protocol belongs to this layer; it can be looked as an IP address translation approach. The Physical/Link layer of the OSI model are handled as one layer in the TCP/IP model. The raw transmission of data over the physical medium is handled here. Ad- dress Resolution Protocol (ARP) at this layer maps t.he 32-bit IP address used in the network layer, to the 48-bit link layer or physical address. The protocol supporting mobility should be above this layer such that it is technology independent and supports host migration across homogeneous as well as heterogeneous media; that is, it should not make a difference whether the mobile host moves from one Ethernet to another or from an Ethernet to a wireless LAN.

1.2 Motivation for Mobile IP

High speed, ubiquitous connection to the Internet and seamless transition from home to work to wherever would mean an endless array of applications. In the prevailing Internet Protocol (IPv~),it is assumed that a node's IP address uniquely identifies the node's point of attachment to the Internet. Hence to receive datagrams addressed to it, a node should be at this specific location on the network. This restricts its mobility completely. By Internet mobility we refer to a node being away from its "permanent" IP address and still be capable of receiving packets addressed to its permanent address at its current point of attachment. Internet mobility should also allow the mobile host to source and send packets to correspondent hosts. Both the processes should be operational without informing correspondent hosts the change in its IP address.

Mobility introduces the possibility of dynamic changes in the network and link conditions. For instance, from home a modem could be used for communication; at the office, access to a wireless LAN would be available in the corridors and conference halls; the personal cubicles would have an Ethernet link for the laptop. These changes in network conditions should be transparent to the applications and the users i.e. the user of a mobile node or a corresponding node does not have to know the current point of location of the mobile node on the Internet or subjected to any performance degradation due to mobile host protocols.

With considerations to backward compatibility, protocol requirements, interoperabil- ity and existing infrastructure, the mobility of a node in the Internet is accommodated in the Mobile IP approach by enhancements to the existing IPv4 protocols. Mobile IP provides transparent routing of IP datagrams to the mobile nodes anywhere in the Internet.

1.3 Organization of Thesis

The outline for this thesis is summarized below. We first discuss the growth and indispensability of Internet and computers and hence the need to support Internet mobility. A brief background about Internet protocol architectures and the effect of integrating mobility on the TCP/IP protocol layers is provided. In chapter 2, we deal with the Internet addressing scheme and how it leads to the mobility problem. This is followed by requirements or constraints to be considered in any approach to support mobility. Mobile IP approach and operations and other related work are described in this chapter. In chapter 3 we deal with the concepts of Mobile IP protocol and the implementation considerations to be taken into account. In Chapter 4, we handle the implementation details of our Mobile IP approach. The performance tests and results of our implementation are discussed in chapter 5. In the last chapter we conclude based on our findings and explore the scope for future work. Chapter 2 Internet Mobility

Mobile hosts could be either migratory users who are stationary but the network they are connected to is different from time to time or roaming users who are actually on the move and would like continuous, uninterrupted connection while moving. The current version of IP does not support Internet host mobility.

2.1 Internet Addressing Scheme

The IPv4 system uses two-level hierarchical routing [Tan961 for directing packets to networks attached to the Internet backbone. The addressing scheme for the TCP/IP suite is illustrated in Fig. 2.1. In the absence of an address hierarchy, backbone routers would be forced to store and maintain routing table information about the reachability of every network and Internet hosts in the world. Given the vast number of IP subnets, managing and updating route tables for the growing Internet is infeasible. Hierarchical addressing makes routing scalable.

Subnetting and Classless Inter Domain Routing techniques have been deployed in recent years to deal with the problem of running out of address space. The IP address contains the network identification and the host identification number with a Lowest Highest 012 ,8 16 24 3 1 Address Address 10 netid 1 hostid I Class A 0.1.0.0 126.0.0.0 I I I I I I 110 netid 1 hostid 1 Class B 128.0.0.0 191.255.0.0

1 110 netid I hostid I Class C 192.0.1.0 223.255.255.0

Figure 2.1: .Addressing scheme in TCP/IP Internet structure. In the two-level hierarchical routing, routers across the Internet are responsible for routing packet to the correct network or subnet. It is the concern of that network to route the packet to the correct host based on the host number. The routers just maintain a network topology information of individual networks. Addi- tional support for hierarchy is being designed for IPv6.

Mobility Problem

The hierarchical addressing scheme leads to the host mobility issue. The datagrams or packets to a mobile host are sent to its home network based on its network id. If the mobile host is not on that network it loses its packets. In essence, when a mobile host moves, it changes its point of attachment and loses its network connection and higher layer applications are disrupted.

The possible alternatives if a node wants to be mobile and still be able to communicate

the node should change its IP address every time it moves, and broadcast or multicast this change over the Internet

host-specific routing must be propagated.

A TCP connection is identified by a tuple

The first alternative implies that the TCP identifier for that connection changes and hence transport and application layers connections are lost when the point of attachment is changed. Also, there is a problem of informing and updating the corresponding nodes and intermediate router databases. The second choice of host- specific routing indicates enormous scaling problems given the huge number of hosts in the general Internet. Propagating host specific routes for even the mobile fraction of these hosts across the entire Internet is an infeasible solution. Also, the possibility of the mobile host changing its location frequently would make the whole approach impractical.

2.3 Mobility Support Requirements

With considerations to backward compatibility, protocol requirements, interoperabil- ity and existing Internet infrastructure, the requirements and constraints to support Internet mobility could be stated as

Changes to the existing IP infrastructure should be minimum and provide backward compatibility

No additional burden on the diminishing address space

No software changes at the routers or tables or fixed hosts other than mobility support entities

After changing its link layer point of attachment, a mobile node should be able to communicate with other hosts, without changing its IP address

A mobile node should be able to communicate with nodes irrespective of whether they implement the enhanced mobility functions

All update messages to other nodes regarding the location of the mobile node must be authenticated to protect against remote redirection attacks The transition should be transparent to the higher layers i.e., regardless of the new location of the mobile node the transport and higher layers should offer uninterrupted services

The Internet Engineering Task Force(1ETF) set up a ~'lTireless/MobileHosts(h3obile IP) Group to propose and evaluate schemes to support mobility in networks. The mobility of a node in the Internet is accommodated by protocol enhancements to the existing IPv4 protocols.

2.4 Proposals to Address Internet Mobility Issue

Vl'ith the increasing demand for Internet mobility, several schemes were proposed to support mobile hosts on the Internet. Most of these proposals differed in the mechanisms adopted for mobile host location updates and management, procedures to resolve address translation - key approaches to solving the mobility problem. The entities and functionalities included to support mobility also varied between protocols. In the sections below we are going to briefly outline various protocols different from the Mobile IP protocol, which is standardized by the IETF, to give an idea about the evolution and overall benefits of the Mobile IP protocol. Comparisons between these protocols [MS94] and how well they meet the requirements put forth by the IETF would also be discussed.

2.4.1 Columbia Scheme

In this scheme, proposed by Ioannidis and Maguire, [IM93] all the mobile hosts have addresses in the same IP subnet, the virtual mobile subnet. This mobile subnet contains unconnected physical network segments called cells. Mobile Subnet Routers(MSR) serve mobile hosts in one or more cells. The packets to the mobile subnet have to be routed through the MSRs. These MSRs advertise routes to the virtual subnet using normal Internal Routing Protocols. The MSR nearest the virtual subnet is used as an entry point to tunnel the packets to the mobile host. If the mobile host is local to this MSR's cell, the datagrams are directly forwarded to the mobile host. If the entry point MSR does not serve the mobile host, but knows which MSR does, it encapsulates the mobile host's datagram and sends it to that MSR. If it does not know who serves the mobile host, it multicasts a query to the other MSRs. The MSR handling that mobile host responds and this is cached. When a mobile host moves to a new cell it registers its current position with the MSR in that location and informs the MSR in the old cell to forward its packets to the new location. Mobile Internetworking Control Protocol [IM93] is used for discovering and distributing mobile host's' information. IP-in-IP [Per96a] protocol is used for encap sulation between MSRs. These protocols effectively hide the partitions in the virtual subnet making it appear as a seamless subnet.

Thus, only the MSRs would have to know or cache the location of the mobile host. Intermediate or backbone routers would not need to have any information about the mobile host. This design puts additional burden on the address spaces since each virtual subnet has to be able to support the maximum number of mobile hosts. There is also considerable load on routing protocols since the MSRs are required to advertise their connectivity to the virtual subnet periodically. This implementation works well within an organization or campus but does not scale well in wide area networks and does not provide effective scaling over the entire Internet.

2.4.2 Sony

In Sony's scheme [MS94], the mobile host acquires a temporary address in a new network. The mobile host sends its temporary IP address and its permanent home IP address to its home gateway. Packets originating from the mobile host has a mapping for the temporary IP address and the destination address. Intermediate routers could cache this mapping for future routing thus avoiding every packet to be routed through the home gateway. Similarly packets addressed to the mobile host could also carry the mappings. If routers have an entry for the mobile host in a mapping table they forward the datagram to the mapped temporary address; otherwise, it is routed through the home gateway. An additional IP Option to carry identifier and management information is also described.

As is clear, this proposal involves modifications to host and router software in addition to changes to the IP packet by the inclusion of a new IP option. It also needs data link layer support to indicate migration of the mobile host. Managing the cache entries in the routers is difficult since some caches could be obsolete and hence will lead to inconsistencies. There is also an additional burden on address space.

2.4.3 Loose Source Routing

This proposal [Joh][Bha95], uses the IP Loose Source Record Route (LSRR) option. In this option, the datagram is first routed to the router in the destination address field in the IP header. At that header, the destination address is replaced by the first address in the LSRR option and so on until the end of the option is reached. To record the route, each router copies its address in that entry which it copies into the destination address field.

This LSRR option is used for routing packets to the mobile host by setting the source route of the datagram to the router in the foreign network to which the mobile host is attached. Each mobile host is associated with a home network where it is assigned a permanent address. There is a database of the location of all the mobile hosts maintained and updated by gateway(s) connecting this home network to the entire Internet or by separate mobility support hosts in the home network. When a mobile host moves, it notifies its home gateway which updates the database. The home agent uses proxy ARP to intercept the mobile hosts datagrams. When the mobile host receives datagrams while away, the datagrams are routed using LSRR option by setting the destination as the foreign network and also informs the correspondent host about the change in location which could be cached by intermediate routers for future communication. When the router or support host in the foreign network is notified that a mobile host is visiting it, it enters this information in its database. After the datagram is received by the router at the foreign network, it delivers it to the mobile host at its physical address in this network acquired during registration. ICMP messages are used to send mobile host movement notification and reply and for host redirects.

This protocol avoids burden on the IP address space. There urould not have to be extensive changes to the software at the backbone routers unless for caching purposes and for updating caches at the intermediate gateways. The packet overhead introduced by IP-in-IP encapsulation is avoided. This protocol also scales well. But since this is an IP source option, it would need extra processing in the routers.

From the above discussion, we see that these previous works, especially the Columbia and the Sony implementations did not meet the essential goals of no changes to host or backbone router software or configuration. The Columbia protocol requiring MSR support, would work well within an organization but would not scale well over the entire Internet. The Sony protocol needs address mapping tables and software and configuration changes at the hosts and routers. Both these protocols need alterations in the existing infrastructure and need additional address spaces. The LSR protocol though scalable needs backbone routers and correspondent hosts to cache the mobile hosts address away from home and update this cache. This propagation of cache would involve additional software and routing table entries in the routers for optimal routing and this feature conflicts with our goal of no changes in existing intermediate router(s) .

The limitations on these protocols with respect to the IETF specifications and con- current research and parallel improvements lead to the evolution of the Mobile IP protocol as it is now. The Mobile IP protocol in our implementation is similar to LSR in that it uses routers to support the mobile host. To redirect the packets to the mobile host, the routers use IP-in-IP encapsulation instead of LSR to avoid overhead at intermediate routers. Also, there is no caching of the mobile host's current location anywhere else except at the home network. The correspondent host could cache this but is not required to do so. Thus, the modifications are restricted to the configuration of mobile host and routers supporting it. This Mobile IP protocol architecture has been designed to be compatible with the IETF standards. The next section gives an introduction to the Mobile IP protocol and brief operation detail.

2.5 Overview of Mobile IP

Mobile IP architecture [Per96b] has been proposed and standardized by the IETF Mobile IP Working Group to provide continuous, seamless connectivity to the network. This IETF Mobile IP protocol satisfies the requirements as per specifications , by providing backward compatibility, transparent routing of IP datagrams to mobile nodes in the Internet.

The permanent home IP address of the mobile node does not change. Packets addressed to the mobile node are first routed to its permanent home network, where the packets are intercepted by a router in the mobile host's home network. The mobile host registers its temporary IP address in the foreign network with this router every time it moves to a new location. With this information about the most recent location of the mobile host, the router in the home network tunnels the packets it intercepts on behalf of the mobile host to the mobile host's latest point of attachment to the Internet. A router on the network the mobile node is visiting provides the temporary IP address for the visiting mobile host, decapsulates the encapsulated datagram arriving from the router in the home network and directs it to the visiting mobile node. 2.5.1 Mobile IP Terminology

The following definitions describe the functional entities and components of Mobile IP architecture.

Mobile Host (MH) is an Internet host or node which can move around changing its point of attachment frequently but capable of sending and receiving packets addressed to its home IP address irrespective of its current location.

Home Network The permanent home IP address of the mobile host is allocated from the address space of this network(s) or subnet(s). A mobile host could be reserved in more than one home network.

Foreign Network Any network on the Internet other than the home network to which a mobile host can attach when away from its home network.

Home Agent(HA) is the mobile support node on the home network which tracks the current location of the mobile node. The home agent intercepts the mobile host's packets and redirects it to the mobile host in the foreign network.

Foreign Agent(FA) provides support for mobilit,y in the foreign network the mobile node is visiting. It assigns a temporary "care-of address" to the mobile node, decapsulates and forwards packets tunneled to the mobile node.

Correspondent Host(CH) is the host with which the mobile host is commu- nicating

Care-of Address is an IP address of the foreign agent with which the mobile host is registered. Co-located care-of address is a temporary local IP address acquired by the mobile host in the foreign network.

.A home network could also function as a foreign network to other mobile hosts visiting .it. The foreign agent and the home agent are termed mobility agents. Home Network

T Home Encapsulated Redirected Agent ' Packet ------Foreign Network j Mobile : , Host )------, I L------~ I - Foreign I Agent

I Mobile .------Host Mobile Host Migrates

Figure 2.2: IETF Mobile IP Protocol

2.5.2 Operation of Mobile IP

The design and operation of the Mobile IP protocol is summarized for better grasp and understanding of the implementation procedures. Fig. 2.2 illustrates this protocol.

Mobility agents (home agents, foreign agents) advertise their presence on links by sending Agent Advertisement messages which are extensions of ICMP Router Advertisements. These advertisements contain the available "care-of address1' (foreign agent only) and home/foreign agent bit status and are sent at a nom- inal periodic rate. A newly arrived mobile node could solicit agent services by sending Agent Solicitation messages, similar to ICMP Router Solicitation.

The mobile node comes to know of its current point of attachment from the Agent Advertisement messages.

If in its home network, the mobile host does not use mobility services. If it is returning to its home network it deregisters by exchanging Registration Request and Reply messages with the home agent.

If the mobile node finds itself in a foreign network, it obtains a care-of address (an IP address of foreign agent) or a co-located address. The co-located address is a temporary IP address acquired by the mobile node by mechanisms such as DHCP, in which case the mobile node acts as the foreign agent. In this case, the mobile host is the endpoint of the encapsulation tunnel and decapsulates its own packets.

When operating from a foreign network, the mobile node registers its new care-of address with the home agent by exchanging Registration Request and Registra- tion Reply messages. Depending on the type of care-of address, foreign agent's care-of address or co-located care-of address, the mobile node registers with the home agent, either through the foreign agent or directly. The home agent could choose to reject a Registration Request.

Datagrams arriving at the home network addressed to the mobile node are intercepted by the home agent using proxy or Gratuitous ARP. The home agent encapsulates these datagrams and tunnels to the mobile node's care-of address. The datagram received at the tunnel end-point either by the foreign agent or the mobile node itself, is decapsulated and finally delivered.

Datagrams from the mobile node could be routed directly, not necessarily pass- ing through the home agent, with the mobile node's IP address as the source address.

In the following chapters dealing with implementation details, these steps outlined above would be described in more detail where necessary. In our implementation we do not use foreign agent and hence the changes in host and router is minimized. We will look in detail at our implementation in the next chapter. Chapter 3 Concepts of Mobile IP Protocol

In this chapter we will discuss the operating details and concepts behind our implementation of Mobile IP. MTewould also outline previous related implementations and evaluate the differences.

Our implementation of Mobile IP is based on the IETF specifications [Per96b] and compliant with the standards set up by the IETF. The protocol we have implemented does not require any changes to backbone routers or other hosts. There are software modifications in the home agent and mobile host to configure them to support mobility. Our approach does not use a foreign agent. The reasons for this and the advantages and disadvantages of this approach would be discussed later in this chap ter. In the subsequent sections, we discuss in detail how the additional functionalities and responsibilities of the mobile host and home agent' are handled.

3.1 Agent Discovery

The agent discovery mechanism is used to establish a binding between the mobility support agents and the mobile host. 3.1.1 Agent Advertisement Message

The mobile host has to determine whether it is in its home network or foreign network. It discovers its current point of attachment to the Internet by looking at the Agent Advertisement messages. Agent Advertisement messages are sent by mobility agents to inform that their services as mobility agents to support mobile hosts are available. These are normal IChilP Router -Advertisement messages [Dee911 with a Mobility Agent Advertisement extension as shown in Fig. 3.1. This extension indicates the number of care-of addresses available and lists the addresses if it is a foreign agent. The Lifetime field indicates the maximum length of time the agent is willing to support the mobile host. It uses flags to indicate whether the service offered is as a foreign agent(F) or a home agent(H), whether Registration is required(R) and the encapsulation techniques applied (M, G, I*).A foreign agent can refuse services to a mobile host if it is busy(B). A home agent should always support a mobile host, though it can refuse registration if the request is not authenticated.

Router Advertisement Message

Mobility Agent Advertisement Extension 11 11111 I

zero or more care-of addresses

Figure 3.1: Mobility Agent -Advertisement Message 3.1.2 Mobile Host Migration Detection

The ÿ no bile host uses the Registration Lifetime field or the network prefix in a Prefix- Lengths e~t~ensionto determine if it has moved. If the mobile host receives advertisement messages from the same agent or another agent while nearing expiration of its registration it should reregister with that agent. If a mobile node receives .Agent Advertisement from its own home agent it has come to its home network.

3.1.3 Agent Solicitation Message

A mobile node can solicit Agent Advertisement Messages by sending ICMP Router Solicitation message [Dee911 with the TTL (Time To Live) field set to 1. This would prompt advertisements from the mobility agents in that link.

3.2 Mobile Node Registration

Registration is the procedure where the mobile host informs its home agent about its current point of attachment. The home agent delivers the services the mobile host requests.

3.2.1 Role of the Mobile Host

A mobile node initiates registration whenever it detects it has moved or when lifetime of its registration expires. The registration procedure allows the mobile host to provide information about its current location to the home agent and establish a mobility binding between its home address and care-of address for a specified length of time. The mobile host could register via the foreign agent or directly with the home agent. If the mobile host is using the foreign agent care-of address or registration is required for the link, it has to register through the foreign agent. If the mobile host uses a co-located care-of address (temporary IP address) or is back in its home network it registers directly. Security associations are established between the mobility agents and the mobile host to authenticate and protect further correspondence.

3.2.2 Mobility Agents' Role

For registering via the foreign agent, the mobile host sends the registration request to the foreign agent. The foreign agent processes the request and sends it to the home agent. The home agent validates the request and sends a valid registration reply to the foreign agent granting or denying mobility binding. The foreign agent delivers the reply to the mobile host after processing.

The mobility agents and mobile node should provide Mobility Security Associa- tion(MSA) to authenticate registration. We will see more details about security later.

3.2.3 Registration Message Format

User Datagram Protocol (UDP) [Pos80] is used for registration messages. The source address in the UDP header is the address from which the message is sent (co-located care-of address or mobile host's home address) and the destination address is either the foreign agent or home agent as the case may be. As Fig. 3.2 illustrates, the UDP header is followed by Mobile IP fields indicating whether it is a Registration request or reply, the lifetime of the registration to indicate how long mobility services would be offered, and the IP addresses of the home agent, the mobile host's home address and its co-located care-of address. A 64-bit Identification number is used in the Registration message,to match requests and reply. Authentication extensions are provided to avoid redirection attacks. UDP Header

I Type Lifetime I Home IP Address 1 1 Home Agent IP Address I I Care-of Address (End point of Tunnel) I

Identification

Figure 3.2: Mobility Node Registration Request Message

3.2.4 Registration Reply from Home Agent

The home agent receives the registration request and evaluates the authenticator in the Authentication extension. Keyed-MD5 [Riv92] is used to compute the checksum over the secret binding between the mobile host and home agent, and the UDP payload and extensions. It also looks at the services or bindings the mobile host requests and evaluates if it could support these and updates its record of mobility bindings. The home agent is configured with the home address and MSA of each mobile host it supports as a home agent. Based on the validity of the request, the home agent sends a reply with the matching Identification field and a code field to denote acceptance or denial of the request. This reply is processed by the foreign agent and the mobile node for authentication and to verify and evaluate the mobility bindings and the services provided.

The mobile node has to register again when the lifetime of the registration is near expiration. Multiple registrations with the home agent is allowed. Registration request could be denied if the lifetime requested or provided is considered too long by either or both of the mobility agents, or if the Identification field does not match. In our implementation, we do not use a foreign agent. So, the above Registration procedure is carried out by the mobile host using a co-located care-of address it acquired using Dynamic Host Configuration Protocol(DHCP) [Dor97].

3.2.5 Security Concerns for Registration Mechanisms

Mobile IP implementation involves the tunneling of the mobile node's traffic to its care-of address. An IP datagram carried as payload within another IP datagram is termed to be encapsulated. This encapsulation and decapsulation of a datagram to alter the normal IP routing is called Tunneling. This could lead to a potential security breach if the mobile host's registration with the home agent were unauthenticated. There could be an adverse host masquerading as mobile host and maliciously redirecting the mobile host's traffic to itself by forging a registration request to the home agent to send the mobile node's packets to a false location. Similarly there is also a possibility of host masquerading for home agent and foreign agents and there arises a need for mobility agents and mobile nodes to authenticate, verify and encrypt their messages to one another based on mobility security associations.

MD5 Message-Digest Algorithm for Authentication

The mobile host and home agent share a secret MD5 key for authentication purposes. This algorithm takes any message of arbitrary length and produces a 128-bit distinct "message digest" or "fingerprint" of the message. It is infeasible to have two messages with same message digest (difficulty to the order of 264)or produce a message with a target message digest (difficulty to the order of 2128). For keyed MD5 authentication in Mobile IP, the shared secret key is known only to the mobile node and the relevant mobility agents involved in the mobile node registration since only they need to know the shared key used for computing the 128-bit digest. Replay Protection for Registration Requests

If a valid registration request is stored by a adverse host, this could be replayed later to divert the mobile node's traffic maliciously. To avoid this the mobile node and the relevant mobility agents should resolve, in their Mobile Security Association, a mechanism of replay protection using timestamps or nonce or both in the Identifica- tion field of the Mobile IP header. The Identification field is read depending on the method of protection used. The low-order 32 bits of the Identification field are dupli- cated unchanged from Registration Request to Reply. A foreign agent uses this 32-bit along with mobile node's home address to match replies with requests. To secure it further, repetition of the Identification in consecutive requests are disallowed.

Timestamp Replay Protection The mobile node includes the time of day in its registration request. On receiving this request the home agent verifies the Identifica- tion field and if the timestamp is close enough to the home agent's clock and greater than all timestamps in previously received requests from the mobile node, it copies the entire Identification field in its reply. If the timestamp check by the home agent fails, it replaces the mobile node's timestamp with its own time of the day in the reply. The mobile node on receiving this rejection of its Registration request, checks if the low-order 32-bit in the Identification is the same and then synchronizes its clock based on the home agent's timestamp. Nonce for Replay Protection The home agent computes the pseudo-random nonce and inserts it in the high-order 32 bits of the Identification field of every registration reply. The mobile node verifies the low-order 32 bit of the home agent's reply with its request. On a valid verification, it saves the high-order 32 bit to send with the next request. Thus, the home agent uses a new high-order value, while a mobile node uses a new low-order value for every request. The foreign agent uses this low-order value to match every reply to the pending requests. If a registration request is rejected because of an invalid nonce, the new nonce is stored by the mobile node for subsequent requests, thereby synchronizing its requests to the home agent for validation. 3.3 Routing and Packet Redirection Mechanisms

In this section we will discuss how I\-e handle routing and packet redirection to route packets to and from the mobile hosts irrespective of their point of attachment.

3.3.1 Intercepting Mobile Host Packets

When the mobile host is in its home network, its packets are routed following normal IP protocols without mobility services. When the mobile host moves and successfully registers its current care-of address nith its home agent, the mobility agents redirect and deliver its packets to its new location. In our implementation, we work with no foreign agent and the mobile host registers its co-located care-of address with the home agent. After Registration the home agent uses Gratuitous ARP [Corn951 xto update the entry for the mobile node's address as its (home agent) own link-layer address. If there are any ARP requests for the mobile node the home agent uses proxy ARP to reply to such requests with its own address, if the mobile host is in its mobility binding cache. This way the home agent intercepts any packets for the Mobile Host. If the mobile host has to send any packets, it tunnels them to the Home agent which decapsulates it and sends it the correspondent host whose address is specified in the inner-IP header.

3.3.2 Tunneling Packets to Mobile Host

The mobile host uses IP-in-IP [Per96a] to encapsulate the mobile host's packets and tunnels it to the co-located care-of address of the mobile host. Encapsulation is the method employed in redirecting the mobile node's datagrams, which are intercepted by the home agent, to the correct destination in the foreign network. The encapsulated datagram is decapsulated by the foreign agent (or mobile node itself) and delivered to the mobile node. In Mobile IP approach the home agent and the foreign agent are the endpoints of the tunnel. In IP-in-IP encapsulation, an outer IP header is included before the original IP header by the host (like home agent or foreign agent) at the entry of the tunnel. This is used in our implementation.

Figure 3.3: Mobile IP Tunneling using IP-in-IP

Mobile IP Encapsulation: Header Fields

Most of the outer IP header fields are set depending on the inner IP header, the tunnel MTU, appropriate time for delivery as shown in Fig. 3.3. The encapsulator IP address and the decapsulator IP address are recorded as the source and destination addresses. Only the TTL field of the inner IP header is changed. The choice of security options of outer header is affected by those in the inner IP header. Mobile IP Encapsulation: ICh4P Management

In case the home agent receives some ICMP message from an intermediate router within the tunnel, depending on the type of the ICMP message, a similar IChlP message is "relayed" to the originator (corresponding host) of the unencapsulated, original message. This "relaying" is done after stripping the outer header from the returned copy of the datagram. The encapsulator could also decide not to relay the message to the correspondent host depending on the type of message. For instance, Source Route Failed, Source Quench, Redirect etc. should be handled appropriately by the encapsulator or home agent. The home agent which encapsulates these messages should maintain information about the MTU, path length and reachability of the tunnel. These are updated depending on the IChlP error messages.

3.3.3 Security Concerns for Tunneling

Internet security is considerably undermined by employing IP encapsulation. Filter- ing of datagrams based on header fields is infeasible since the original header fields including Source and Destination -Address, protocol fields in the inner original IP header are displaced from their normal position by the additional outer header. Since any datagram can be encapsulated in a harmless outer header and passed, the gateway routers should subject all the datagrams to careful scrutiny. Both intermediate routers and the final host at the endpoint of the tunnel should exercise care while handling encapsulated datagrams. For example, a particular correspondent host might not be allowed to communicate with hosts in a specific subnet which the mobile node is visiting. But once the datagram from this host is camouflaged in the home agent's header, it is allowed in to the foreign subnet.

The routers in a tunnel should hence be aware of encapsulation protocols to correctly filter incoming datagrams. If this filtering is coupled with authentication of the encapsulating packet and the encapsulated inner packet as sent by a trusted source, the potential risk is greatly reduced. The foreign agent or mobile host receiving the encapsulated packet should ensure that the encapsulating outer datagram is from an authenticated and trusted home agent. It also has to verify that the inner datagram has an IP authentication header and the destination address in the inner datagram belongs to the network interface of the foreign agent or with some mobile node visiting it, with which it has arranged a special relationship.

3.3.4 Other Security Schemes for Mobile IP

IPSec protocol [ZC97, KA951 provides high quality, interoperable, cryptography based security services including access control, data origin authentication, confi- dentiality (encryption) and connectionless integrity. This protocol could be used to protect Mobile IP redirection tunnels. Rapid Authentication [ST971 is another scheme proposed to establish security associations with a mobile host in the foreign network. If a mobile node has to switch networks several times, this protocol which uses kerberos style key distribution could be used. There are also proposals [MG98a, MG98b, AP95] which are essentially schemes to negotiate firewalls when the mobile host is in a foreign network. The SKIP protocol, which favors session-less key distribution, has very low overhead involved in the establishment of security bindings. For firewall traversal, an association has to be established between the firewall router and the home agent to successfully route packets to the mobile host. These protocols though haven't been implemented in this implementation. 3.4 Implementations with a Foreign Agent

The CMU Monarch Mobile IPv4 project runs on NetBSD 1.1 and 1.OA releases and FreeBSD 2.2.2 and 2.2GAMMA releases. This implementation is compliant with the IETF Mobile IP protocol. It works with foreign agent support. Both minimal encapsulation and IP-in-IP encapsulation are supported. Timestamp and nonce are used to ensure Replay protection.

In the Columbia University's implementation, Mobile Support Routers are used in a virtual subnet to which the mobile hosts belong. This implementation works well within a campus or organization and is not scalable over the entire 1nt)ernet.

The State University of New York, Binghamton provided the first implementation of Linux Mobile-IP [DG96b], [DG96a]. This software runs in user space. A foreign agent is assumed available on all foreign networks the mobile host can visit. If foreign agent support is not provided, the mobile host uses a dummy interface and proxy ARP to collect its packets. This is done with a slight change to the mobile host software. This implementation supports nonce replay protection. This implementation has some problems with ARP and simultaneous registration issues.

The HP Labs, Bristol, UK implementation runs on Linux platform in user space and complies with the IETF Mobile IP. The implementation in NSU, Singapore [Yun97] has the mobility agents and the mobile host built in Linux kernel.

3.5 Design without Foreign Agent

This section will deal with the advantages and disadvantages of Mobile IP implementation in the absence of foreign agent(Fig. 3.4). In our implementation without the foreign agent, the mobile host can move to any network irrespective of whether the network provides mobility support or not. If the network has a router configured to act as a foreign agent to visiting mobile hosts, then this protocol would use the foreign agent as the end point of the encapsulation tunnel between the home subnet and foreign subnet. This approach reduces the dependency on services offered by foreign network, reduces the effective changes to the existing protocol and ensures a simpler implementation.

Home Network

1 He;+.capsr Redirected Agent Packet Foreign Network """'------;------, I 1 L ------1 I I I I I Mobile .------Host Mobile Host Migrates

1 1

Figure 3.4: Mobile IP protocol without foreign agent

Advantages

a Mobile hosts can function in network with no foreign agent support. Reduced dependency on foreign network.

a Every network connected to the Internet does not have to configure a foreign agent to support visiting nodes. This simplifies the approach at the user level and reduces scaling issues. We only need to configure home agents in any mobile host's home network. The need to convince every independent Internet authority to provide foreign agent services is completely removed.

a The foreign agent is a single point of failure. We do not have control over the foreign network to fix or restart a crashed foreign agent as we would have in our home network. When a foreign agent agent fails it takes with it the communication capabilities of the visiting mobile hosts it is supporting. Leaving the foreign agent out in our implementation we avoid this threat and our mobile host can correspond with the outside world as long as it runs and the home agent is up.

The mobile host does not have to fall in line with the constraints set down by foreign agent. It sets its binding and lifetime depending on its understanding with the home agent.

This approach is compatible nith the IPv6 approach [PJB99]. With a much larger IP address space, the IPl-6 approach offers support for caching bindings between home address and temporary care-of IP addresses reducing the role of foreign agent and optimizing routing from or to the mobile host.

Disadvantages

a Acquiring a temporary IP address by DHCP could be a problem for a mobile host in a foreign network. Some networks might have policies against providing or sharing resources with foreign hosts.

This approach also involves a burden on the limited IPv4 address space. If a network does not have IP addresses to spare, the mobile host cannot function from this network unless it gets a temporary IP address.

When the mobile host moves, it loses any packet which is en route. Any packets the home agent tunneled to the mobile host, before it received the new registration will go to the old network and be lost. If a foreign agent approach had been used, the foreign agent in the old network would collect these packets and send them to the new location of the mobile host or the home agent depending on the implementation. But the trade-off here is a simpler implementation and reduced cost to packet loss. When the mobile host A, leaves a foreign network, an incoming new mobile host B, could acquire A's old temporary IP address. In this case, any packet en route for A sent by A's home agent before it received A's new registration would erroneously reach B. This could lead to eavesdropping. But most DHCP servers, do not allocate same IP addresses for a long intervening time interval which helps prevent such mishaps.

The mobile host design and software is more complex since it has to be configured to play the role of a foreign agent. The mobile host, in this case, would have to be aware of physical network connectivity and changes to physical network interfaces. Also, the mobile host should be capable of performing decapsulation arid encapsulation based on the IP-in-IP or minimal encapsulation or GRE protocol to receive and send packets.

This implementation is based on the MosquitoNet project [BXCS96, BX971 at Stan- ford University. This resides partially in the Linux kernel and uses co-located care-of address in the absence of a foreign agent. This implementation and the software configurations on the mobile host and home agent will be discussed in more detail in the next chapter. Chapter 4 Implementation of Mobile IP on Linux

This chapter deals with the description of the setup and implementation details of our approach to the Mobile IP protocol. The configuration of the hosts to support mobility services will be discussed. This chapter also handles the software on the mobile host and the home agent and the responsibilities and roles of these entities.

4.1 Why Linux?

Internet mobility is essential for people on the move who use portable personal computers. Hence, Linux operating system which is essentially a version of UNIX, has been chosen as the platform for our implementation. Linux source code is available as a free distribution allowing changes to the source code to suit our needs and implementation requirements. Thus, with the advantage of easy and free distribution of source code to the Internet community, Linux emerges as an attractive choice for our Mobile IP development project. 4.2 Mobile IP Installation

In this section we describe the physical setup of the mobile host and home agent machines. This is followed by the kernel setup and the modifications of the kernel source code to support hlobile IP. The kernel and software support on the mobile host and the home agent to provide mobility services is also discussed. Details of the kernel modules and the hflobile IP components which are essential for the mobility support are described.

4.2.1 Physical Setup of the Hosts

In our implementation me have two computers acting as the mobility hosts running Linux 2.0.36 kernel. They are connected via Ethernet cables to the local subnet 132.235.15.0 which is the ece.ohiou.edu domain. The IP address of the home agent is 132.235.15.120 (mobil2.ece.ohiou.edu). The mobile host's permanent home IP address is 132.235.15.121 (mobi1e.ece.ohiou.edu). The Fig. 4.1 shows the physical setup.

Forrip Subnet Network Address: 132.235.X.Y Neunask: 255.255.255.0 Internet

132.235.15.254 Net Addr: 132.235.0.0

Home Subnet I Nenvork Address: 132.235.15.0 Netmask: 255.255.255.0

Figure 4.1: Experimental testbed on the ece. ohiou. edu network

4.2.2 Kernel Modification

The hlobile IP system we have installed is based on the MosquitoNet Mobile IP source code. The installation involves modification of the Linux kernel on the home agent and the mobile host machines to support mobility. The kernel is built by applying the patches which accommodate Mobile IP support. The patches provide modules for virtual interface to facilitate special handling of mobile host's packets and allows IP forwarding or gatewaying. Support for other operatjons including bidirectional tunneling. triangular routing, ARP management and routines for manipulating the Mobile Policy Table is also incorporated within the kernel ding the patch. Other general routines used by the Mobile IP stack for Mobile IP specific functions are also implemented. Thus the crucial changes to the kernel software to implement h4obile IP can be listed as:

IP route lookup function has been altered to access the Mobile Policy Table in addition to the normal IP route table to make routing decisions involving packets originating from the mobile hosts.

A Mobile Policy Table has been included for influencing routing decisions for mobile IP.

The kernel code also supports a virtual link-level interface to encapsulate packets that have to be sent via the home agent to correspondent hosts.

These issues would be discussed in detail in the section 4.3 about the support on the mobile hosts.

4.2.3 Kernel Compilation

After the patches are applied, the kernel is configured to support Mobile IP by se- lecting the corresponding modules. IP forwarding and IP tunneling are enabled in the network configuration. This is followed by compiling the modified kernel source code. The module for including the VIF interface is loaded. This modified kernel is built on both the home agent and mobile host to provide mobility support enhanced with mobility service functions and subroutines. Kernel compilation is followed by user-level compilation of the home agent and mobile host daemon source codes. The daemons are run from the /sbin directory.

Appendix A provides the sequence of steps to load the mobile IP source code and build the modified kernel to support mobility.

4.3 Mobility Support on the Mobile Host

In this section we discuss the configuration files on the mobile host and tlhe responsibilities of the mobile host daemon in establishing a mobility binding with the home agent. This section also addresses the mechanisms for routing the packets originating from the mobile host and addressed to the mobile host.

4.3.1 Migration of the Mobile Host

In our implementation, the mobile host migration is imitated by using DHCP to acquire a temporary IP address for the mobile host. The DHCP server in the foreign network evaluates the request for a DHCP address from the mobile host and allots a dynamic address for a specified lease time and binding time. The mobile host has to renew this IP address after the time specified expires. To return the DHCP address, the mobile host removes the DHCP cache and brings up the interface and configuration associated with its original network when it returns to its home network without rebooting. In our implementation the DHCP server in the 132.235.18.0subnet assigns a co-located care-of address to the mobile host (Fig. 4.2).

After the mobile host has moved to this IP address (132.235.X.Y), it is not accessible in its home IP address (132.235.15.121). Any packets sent to the home IP address would be lost. Hence, to support mobility services the mobile host daemon has to invoked. ethO Foreign Subnet Network Address 132.255 X Y Netrnask. 255 255 255 0 I I I 112235 15 120 I 132 2'35 15 1'21 132 235 15 254 Net Addr 132 235 0 0 Netmrsk 255 255 0 0 Ia / ethl 1 , 1eth0 ethOr( k- Home Subnet Network Address 132 235 15 0 Netmask 255 255 255 0

Figure 4.2: Representation of mobile host migration

4.3.2 Mobile Host Configuration

The mobile host daemon is responsible for procedures related to Mobile IP protocol on the mobile host. It initiates the registration and the deregistration processes with its home agent thereby updating the home agent about its current point of attachment every time it moves.

Configurations for Mobility Binding

The mobile host daemon reads the mobile host configuration file (/etc/mhd.conf) when it is started, to initialize the fields it needs for generating a registration message. The message format has been discussed in Section 3.2.3. This file provides information about the mobile host's home IP address, netmask, the home agent's IP address and the physical interface device. It also specifies the default registration lifetime (1800 seconds in our implementation) and the security associations for security binding with the home agent. The security association is a user selected integer for Security Parameter Index and a 16 byte string as the shared secret key. The mobile daemon uses all this information along with other signals to detect if it has migrated. It determines the interface to send its packets. It establishes a mobility binding with its home agent based on the home agent IP address provided here. Fig. 4.3 shows a sample configuration file. HOME-IPADDR=132.235.15.121 HOME-NETMASK=255.255.255.0 HOMEAGENT-lPADDR=132.235.15.120 HOME-INTERFA CE=ethO DEFA ULT_LIFETIME=1800 SECURITY ASSOCIA TION= 7890 inwbilehostuwhos

Figure 4.3: A sample file for mobile host configuration

Mobile Policy Table Configuration

As mentioned earlier the mobile host daemon routes packets based on the destination address and the source address in the IP packet. The mobile host policies are specified in the configuration file /etc/mpt.conf. The Mobile Policy Table (MPT) which is similar to the normal IP route table is manipulated based on the entries in this configuration. Bidirectional tunneling (Fig. 4.6) and the route optimizing triangular routing (Fig. 4.5) are the two methods by which packets originating from the mobile host are routed either via the home agent or directly to the correspondent hosts.

care-of address=132.235.0.0 netmask=255.255.0.0 entries=2 0.0.0.0 0.0.0.0 80 0 0 0.0.0.0 0.0.0.0 0 1 0 care-of address=O.O.O.O netmask=O.O.0.0 entries=3 0.0.0.0 0.0.0.0 80 0 0 132.235.0.0 255.255.0.0 0 1 1 0.0.0.0 0.0.0.0 0 1 0

Figure 4.4: A sample file configuration for Mobile Policy Table

The mobile policy configuration is illustrated in the Fig. 4.4. Based on the range of the care-of addresses, the kind of traffic or port in use and the destination network the routing policy is configured. In this sample file, t,here are two policy entries to use the care-of addresses in the 132.235.0.0 network. The first entry indicates that for packets to any network (indicated by the first 0.0.0.0, netmask is second 0.0.0.0 in line 4) using port 80 for HTTP traffic, mobile IP cannot be used (first 0) and hence no bidirectional tunneling (last 0). The second entry allows triangular routing with mobile IP for all other traffic. For care-of addresses in any other network, there are three policies including the two stated above. The additional entry indicates for all traffic not using port 80, bidirectional tunneling with mobile IP can be used if the destination address is the 132.235.0.0 network with netmask 255.255.0.0 for the specified range of care-of addresses.

Based on this set of policies, care-of addresses and destination addresses a default entry is added in the Mobile Policy Table (Fig. 4.1) when the mobile host establishes a binding with the home agent. When a packet has to be routed at the IP layer the modified zp-rt-route() lookup function accesses the MPT in conjunction with the normal IP route table before making a routing decision.

4.3.3 Role of the Mobile Host Daemon

The mobile host daemon is responsible for coordinating the various subroutines and mobility support operations to support Mobile IP on the mobile host. In our implementation the mobile host daemon is started at the time of reboot and it runs in the background waiting for signals to evaluate whether it needs to register with the home agent accordingly. After the daemon has been kick started it checks its current point of attachment and updates the home agent if there is any change in its location or when the lifetime of its mobility binding with its home agent expires. Invoking the Mobile Host Daemon

Whenever there is a change in the mobile host's location, the mobile host daemon is invoked by either "mip update" or "mip restart" command. This generates either a SIGCSRl or SIGHUP signal respectively. The signal handler subroutine checks for previous signals and then processes the signal it receives. To facilitate observation of the operations of the mobile host daemon, it is invoked with a -v option for verbose log information and -d option for debugging messages. These messages are written in the /var/log/messages file and can be used to verify if the registration request was accepted and for other additional messages regarding the Mobile IP implementation.

When the mobile host daemon receives a USRl or a HUP signal it rechecks its current point of attachment by looking at its configuration file or its IP address associated with its interface. It then registers with its home agent appropriately.

Registration with Home Agent

When the mobile host finds that it has moved from its home network and acquired a co-located care-of address in a foreign network, it sends a registration request to the home agent. The registration process has been described in detail in Section 3.2. The mobile host daemon establishes a socket interface and sends the registration message with the fields filled appropriately from the information accessed from the configuration file (/etc/mhd.conf). It listens for the reply to its request and then processes the reply. The identification field in the reply is checked to secure against replay attacks. If the identification field in the request and the reply are different, the registration is not validated by the mobile host. The security mechanisms to validate the registration request have been handled in Section 3.2.5.

If the home agent has accepted the registration, and the identification is valid, the mobile host authenticates that the reply is from the home agent by using MD5 digest (Section 3.2.5 to verify the security binding it shares with the home agent. The lifetime of the registration is adjusted depending on the requested and granted lifetime,

If the registration is denied either by the home agent or the mobile host the reasons for the denial is determined and reregistration is attempted after altering the registration message fields suitably.

After the registration has been completed successfully, the mobile host daemon brings up the virtual interface (VIF) device to encapsulate packets. The MIP stack in the kernel is configured with the corresponding state. A Mobile Policy Table is set up and a default entry is added to indicate how packets to different destinations have to be handled.

At this point the mobile host has been set up to support its mobility. Packets addressed to the home address of the mobile host would be encapsulated and tunneled by the home agent to the mobile host's care-of address. Packets originating from the mobile host are encapsulated at the virtual interface and sent to the home agent as IP-in-IP packets to be redirected to the correspondent hosts or sent as normal IP packets directly to the correspondent hosts.

Deregistering with Home Agent

When the mobile host finds that it is back in its home network it flushes the stale ARP cache entries at its neighbors (see Appendix B). It also brings down the virtual interface and turns off the state of the mobile IP module in the kernel and updates other configuration information. It subsequently sends a registration request to its home agent to deregister. Following this the mobile host can receive its packets directly in its home network. 4.3.4 Routing Management for Mobile Hosts

This section discusses the routing policies and decisions undertaken at the mobile host to direct the incoming and outgoing packets. The two routing mechanisms for routing packets based on the destination network are explained. The use of Mobile Policy Table to make routing decisions to optimize the path taken by the packets to the correspondent host is described. This section also deals with the management of packets received by the mobile host from correspondent hosts via the home agent.

Routing Considerations

The mobile IP protocol delivers packets originating and addressed to the mobile host via the home agent. The extra path to the home agent adds latency to the packet routing and delivery. In some cases, the correspondent hosts may be closer to the mobile host than the home agent; this would mean that it would be desirable for packets originating from the mobile host to be routed directly to the correspondent hosts. This forms a triangular route, as shown in Fig. 4.5. The packets to the mobile host are encapsulated and delivered by the home agent. The packets from the mobile host are sent directly to the correspondent hosts thus improving the packet routing and reducing the encapsulation overhead. This would also reduce the bottlenecks at the home agent if the home agent was catering to many mobile hosts. In this case, the source IP address of packets originating from the mobile host (in a foreign network) is the mobile host's home IP address which provides transparency since it appears as if they originate from the home network.

Sometimes security-conscious routers would not allow a packet originating locally but claiming to be from an outside network. Thus, when the mobile host uses triangular routing to send packets directly to the correspondent host, these packets could be filtered by boundary routers. In this case, the packets originating from the mobile host have to be sent to the home agent and redirected to the correspondent host. This is called bidirectional tunneling or reverse tunneling since tunneling is the procedure Figure 4.5: Triangular routing used for routing the packets in both the directions to and from the mobile host and is illustrated in Fig. 4.6 . With bidirectional tunneling optimization of the path the packet takes is lost.

Routing Optimizations

These optimizations of the packet routing is managed by entries in the Mobile Policy Table in IP route lookup. The MPT is read together with the normal IP route table to determine the effective packet delivery mechanisms based on the nature of the traffic. Depending on this, bidirectional tunnel or triangular route is used to deliver packets originating at the mobile host. Round-trip latency is reduced by triangular routing. This technique of using the Mobile Policy Table also ensures backward compatibility with the existing routing table. The route lookup function of the Linux kernel has been modified to accommodate routing policy decisions using the MPT. The range of the care-of addresses, the destination network and the port number in the MPT I 1

Figure 4.6: Bidirectional tunneling determine the type of mechanism to use to successfully route packets. A sample of our Mobile Policy Table cache is shown in Table. 4.1.

Table 4.1: A sample Mobile Policy Table Destination Netmask Port Mobile Bi-dir 0.0.0.0 0.0.0.0 80 0 0 0.0.0.0 0.0.0.0 0 1 0

Support for a virtual interface is also included by modifying the Linux kernel code. The virtual interface handles packets that need to be encapsulated and tunneled. It provides support for ensuring transparency making it seem that the mobile host is still in its home network. As illustrated in the Fig. 4.7, the packets arrive at the IP layer from the top transport layer. These packets could be TCP, UDP or IP-in-IP packets. In the IP layer route lookup function, the normal routing table and the MPT are consulted to determine how the packets should be delivered. For normal IP routing when the source address of the packet is already set, the packets are sent to the appropriate device interface. Packets with unspecified source address that have to be encapsulated are sent to the VIF. Upon receiving a packet, the VIF adds an extra IP header and sets the appropriate source and destination address in the outer encapsulating header. This encapsulated packet is looped back to the IP layer for delivery to the home agent and sent through one of the physical interfaces.

TCP UDP / 0 \ I 0 IP Route Lookup

Mobile Policy Table FlTable

Figure 4.7: Routing with link-layer lirtual interface

When the mobile host receives a packet from a correspondent host via the home agent, it is encapsulated and tunneled by the home agent to the care-of address. It is decapsulated by the mobile host in a procedure reverse to the mechanism of using virtual interface for encapsulation at the mobile host. Also, there exists no routing decisions to be made for decapsulation of the packets at the mobile host. The packet received at a physical interface reaches the IP layer. If it is determined to be an IP- in-IP packet it is delivered to the IP-in-IP transport layer where it is decapsulated. 4.3.5 Summary

Thus the mobile host daemon and the kernel software support and provide mobility services to the mobile host in a foreign network. The configurations and policies on the mobile host influence the establishment of mobility binding with its home agent and other routing decisions. Whenever the mobile host daemon finds that it has moved from its home IP address it sends a request for registration to the home agent. After successful registration with its home agent, the home agent delivers the mobile host's packets after encapsulation to its current location. The mobile host daemon periodically checks the status of its registration lifetime and current location and renews its mobility binding thus providing uninterrupted connectivity to the Internet.

Mobility Support on the Home Agent

The home agent is responsible for keeping track of the mobile hosts to which it offers its services to support their mobility. It redirects the packets arriving for the mobile host at the home network to the foreign network the mobile host is visiting. It also forwards the packets arriving from the mobile hosts to the correspondent hosts. This section addresses the kernel level modifications and the functions handled by the home agent daemon source code. The configuration of the home agent to provide mobility services to the mobile hosts is also discussed. The implementation details governing the establishment of mobility binding with the mobile hosts, interception of the mobile host's packets and tunneling it to the mobile host are also described.

4.4.1 Home Agent Configuration

To configure the home agent system we create a file /etc/had.conf on the home agent. This file specifies the IP address of the home agent, the netmask and the home interface. The details about the number of mobile hosts the home agent supports and their IP addresses in the home network and the corresponding security association each mobile host shares with this home agent are listed. The security associations is based on the mobile host IP address, Security Parameter Index (SPI) and the secret key shared with the mobile host. The SPI is an integer and the shared key is a 16 byte string of our choice. The constraint is that the SPI and the shared key should be identical in the mobile host and the home agent to establish a valid security authenticated binding.

When the home agent daemon is started it accesses the configuration of the home agent daemon from the specified file and sets its configuration of IP address, network interface and netmask. Then it reads the security binding associated with each mobile host and stores it in a mobility binding list. When the home agent daemon receives a registration request it looks up the mobility binding list to see if the particular mobile host is supported and subsequently checks the authentication of the registration request using the corresponding security association obtained from this configuration file. The sample home agent configuration is shown in Fig. 4.8. In our experimental setup, we use one mobile host to test this implementation of the Mobile IP protocol.

HA-IPADDR=132.235.15.120 HOME-NETMASK=255.255.255.0 HOME-IhTERFACE=ethO MOBILE-HOSTS= 1 132.235.15.1217890 imobilehostuwhos Figure 4.8: A sample file for home agent configuration

4.4.2 Role of the Home Agent Daemon

The home agent daemon handles the registration requests from the mobile host and sends valid replies after processing the requests. It uses proxy ARP to intercept the packets the mobile host receives in its home network. These packets are encapsulated using the virtual interface described before and sent to the mobile host. The home agent is also responsible for decapsulating the packets coming in from the mobile host and forwarding it to the correspondent hosts. This section describes these features of the home agent and how they are implemented.

Initializing the Home Agent Daemon

The home agent daemon is started at the time of reboot. To enable verbose informational and debugging messages we invoke the home agent daemon with a -v and -d option. The home agent runs in the background uninterrupted. When the home agent daemon is initiated, it reads the home agent's configuration and updates its entries about the home agent's IP address, home netmask and interface. With the interface name it determines the machine address which could be used for proxy ARP. Following this the home agent daemon obtains information about the number of mobile hosts it supports, the default lifetime of a registration request and the security association parameters - SPI, shared secret key. It then updates the mobile IP module in the kernel based on the IP addresses and home netmask. It creates a socket to listen to the incoming registration requests and establishes a binding.

Registration of the Mobile Host

When the daemon receives a registration request it looks through the mobility binding list to ensure the mobile host with the home address specified in the requested is in the list of mobile hosts it supports. It obtains the mobile-home authentication extension from the message and uses keyed-AID5 (Section 3.2.5) to compute the authenticator. Then it computes its own authenticator from its configuration file to cross-check if both match. It then checks the identification field of the request message to check the timestamp to validate the request against replay attacks. If the timestamp identification fails, it sends its timestamp to the mobile host as described in Section 3.2.5 in the sections for timestamp and replay protection.

After ensuring that the request originated from the mobile host the home agent daemon proceeds with registering the mobile host. It updates the mobility binding of the mobile host with its care-of address and lifetime of the registration. It sends a reply to the mobile host daemon based on the Reply message format discussed in 3.2.4. The reply comprises the lifetime of the registration, the IP addresses of the home agent and the mobile host and a new timestamp id u~hichcould be used for subsequent registration request by the mobile host. It generates an authenticator using keyed-MD5 and the security associations to authenticate and protect the reply from malicious hosts.

Routing Considerations at the Home Agent

The home agent daemon encapsulates all the packets it intercepts on behalf of the mobile host and redirects it to the mobile host's foreign network. The kernel ARP table is modified to set up a proxy ARP entry for the mobile host so that if there is an -4RP request for the mobile host, the home agent answers it with its machine address to effectively intercept the mobile host's packets (Appendix B). Gratuitous ARP is a message sent to flush existing ARP cache entries for a host in the neighboring routers. The home agent sends gratuitous ARP to the hosts in the same subnet to flush the stale entries of the mobile host cached in their ARP tables. This is to replace the cache for the mobile host with its own machine address (or the mobile host's machine address depending on whether the mobile host is in a foreign network or the home network). The neighboring routers and hosts are thus informed to route any packets to the mobile host's home IP address to the home agent's machine address to be routed further. The home agent daemon then adds an entry in the routing table indicating that the packets to the mobile host's home IP address has to be sent to the virtual interface (Appendix B). The virtual interface on the home agent performs the same functions as described in the mobile host configuration in Section 4.3.4. The virtual interface encapsulates the packets from the correspondent host in an IP- in-IP packet with the destination address in the outer header as the mobile host's care-of address. After encapsulation the packets are sent to the physical interface to be tunneled to the mobile host's care of address. For this reason, the home agent sets up a tunnel to the care-of address of the mobile host.

The home agent is also responsible for decapsulating packets received from the mobile host and forwarding it to the correspondent host. When the home agent daemon receives an IP-in-IP packet it is sent to the virtual interface to be decapsulated and then sent to the correspondent host using normal IP. This is similar to the decapsulation procedure at the mobile host and is the reverse of the encapsulation technique carried at the virtual interface. IP forwarding is used to redirect the packet to the correspondent host.

Deregistering the Mobile Host

\?'hen the home agent daemon receives a request from the mobile host to deregister, it authenticates and validates the request. For a legitimate request, it clears the MIP kernel module for the mobile host and updates the mobility binding to remove the registration. It deletes the proxy ARP entry for the mobile host from its ARP table and removes the route entry set up in the routing table to forward packets through the virtual interface. The tunnel to the mobile host's care-of address is also deleted. With the successful completion of all the above operations a mobile host has successfully deregistered. The Appendix B illustrates the difference in the routing table cache, ARP cache before and after registration and deregistration.

4.4.3 Summary

The system and the components on the home agent are configured to provide mobility services for the mobile hosts it supports. The configuration on the home agent influences the support and the constraints in the mobility binding established with the mobile host. The home agent daemon coordinates the establishment of a valid registration, subsequent packet management and routing and the final deregistration of the mobile host. The encapsulation and tunneling of packets received from correspondent hosts to the mobile host or decapsulation and IP forwarding of packets from the mobile host to correspondent hosts to provide transparent mobility support are the essential responsibilities and functionalities of the home agent daemon. The management of various IP layer components and modules including ARP cache, route table and IP-in-IP encapsulation procedures are important features of the mobility management. These issues were described as approached in our implementation in this section.

4.5 Problems and Limitations

In the process of our implementation we faced different problems starting with the kernel configuration to support mobility, acquiring DHCP address and subsequently coming back to the home IP address. All these issues were eventually resolved. The first was fixed by repeated configurations and recompilations of the kernel with the Mobile IP patch. The latter two were handled by using a compatible DHCP software and removing all DHCP caches after relinquishing a DHCP address to ensure smooth transition to the home IP address.

This implementation without the use of a foreign agent provides the mobile host the flexibility of moving to any foreign network without requiring the support of a foreign agent. The disadvantage is the difficulty in obtaining a temporary DHCP address in the foreign network. The scarcity of available free DHCP addresses was one of the major problems we faced during our implementation and experiments. In the presence of a foreign agent this could have been avoided since one of the foreign agent care-of addresses would be allocated to the mobile host. This implementation, though, is compatible with the IPv6 model which essentially wouldn't have any address space problems. For now, the implementation works in a way that it has to be kick started everytime it moves to ensure that it establishes the mobility binding with the home agent, and hence mobility support immediately.

Conclusions

Transparent and uninterrupted mobility support over the Internet is achieved with our implementation of the Mobile IP protocol over the Linux platform with modifications to the kernel source code. Backward compatibility has been ensured by the addition of a Mobile Policy Table on the mobile hosts to route packets based on the destination networks and foreign networks to be used in conjunction with the normal IP routing table. The modifications to the route table cache or ARP cache in the home agent are temporary.

After successful registration, a mobility binding is established between the home agent and the mobile host. Consequently, packet routing between the two entities based on the various policies ensure transparent routing where necessary and appropriate. The packets from any of the protocols whether TCP, UDP, ICMP arrive at the IP layer and are sent to the suitable interface and subsequently routed appropriately ensuring that no other hosts other than the mobile host and the home agent realize the migration of the mobile host.

The next chapter deals with the experimental setup and tests to evaluate the performance of the network in the presence of the Mobile IP protocol. The tests involved TCP, UDP, ICMP packets and FTP protocol. The overhead introduced by the Mobile IP protocol is measured and analyzed.

In Appendix B we have provided sample tables to compare the changes in the network interface, routing tables and ARP caches introduced by the establishment of mobility support which were discussed in this chapter. Chapter 5 Performance Analysis of Mobile IP Implement at ion

This chapter deals with our tests on the Mobile IP test-bed in the 132.235.15.0 (ece.ohiou.edu) subnet. Experiments were conducted to analyze the performance of the mobile IP outside its home network. The tests have been designed to evaluate if the mobile IP implementation operates successfully under various environments. TCP and UDP packets and ICMP messages are sent to the mobile host in the foreign network to measure time delay, packet loss and connectivity. The results of the experiments are tabulated where necessary.

5.1 Description of test-bed

Our test environment, as illustrated in Fig. 4.1, is the ece.ohiou.edu subnet in our Electrical Engineering department. This is the home network of the mobile host. The IP address of the mobile host is 132.235.15.121 and the home agent remains stationary at 132.235.15.120. Both the hosts start their respective mobile support daemons at boot time. The movement of the mobile host to a different location is imitated by first bringing down the physical interface associated with the home IP address and subsequently running the DHCP daemon to acquire a dynamic address. The DHCP servers which offered their services were 132.235.18.X and 132.235.64.X. In the absence of mobile IP services? after the mobile host acquired a temporary DHCP address, trying to reach it at 132.235.15.121 were clearly unsuccessful. Hence, after moving to the new location, the mobile host daemon is given a kick start to start the support services to establish mobility binding with the home agent. At this point the virtual link-layer interface goes up. The routing table changes and a default entry is added to the Mobile Policy Table t.o indicate whether packets have t.o be routed by the triangle route or the bidirectional tunneling mechanism.

The mobile host is now available on the Internet. It receives TCP, UDP packets via the home agent and sends echo response to the ping requests. It can also send packets via the home agent using bidirectional tunneling to correspondent hosts or directly based on triangular routing. The correspondent hosts could be anywhere on the Internet. The mobility services offered is transparent in that there is no way the correspondent hosts can know that the mobile host is at a different IP address.

In the following sections the tests, the data and the evaluation of performance based on this data will be provided.

5.2 Experiments with ping

The ping program is meant for network testing, measurement and network management. It sends ICMP echo request packets to hosts to extract echo response packets from hosts which are running. This is used to determine the status of the host. All hosts are mandated to send response packets and this helps us determine if a host is alive or not. ping could also be used to determine the route the packets take by turning on the record route option. ping also gives us a good measure of round-trip times and packet loss statistics. 5.2.1 Observations I

In our experiments, ping requests were sent to local hosts and geographically remote hosts across the Internet from the mobile host. Data was gathered from the ping packets arriving at the mobile host when it was in its home network and when in foreign network. Observations were recorded in terms of the route taken in both the cases, the number of hops, the packet loss, the round-trip time and the geographical distance of the hosts. Several iterations were carried out. Table 5.1 displays a sample of the data acquired from the iterations. The data is tabulated when the mobile host is in its home network (H) and in a foreign network (F).The table also uses distance as a point of reference to draw inferences. Appendix C has a sample of the results of pinging different remote and local hosts to show the route taken and other details.

From the table, we can draw two types of observations. The first, being irrespective of whether it is a mobile host or not, the general results of ping request to remote hosts. The second set of observations leads us to the performance evaluation of the mobile IP protocol implementation. Table 5.1: Observations of ping requests from Mobile Host

Ntwk Hosts Dist Size Hop TTL Pkt Time H/F Miles Bytes Loss% Min/Avg/Max(ms) H ent .ohiou.edu local 64 4 255 0 212.414 128 4 255 0 2.413.014.4 F ent.ohiou.edu local 64 5 254 0 4.114.717.9 128 5 254 0 4.015.719.3 H eng.buffalo.edu 298 64 9 241 0 67.1/99/290.3 128 9 242 0 681157.51335.8 F eng.buffalo.edu 298 64 9 240 0 67.1/99.0/290.3 128 9 241 0 159/302/609 H cornell.edu 350 128 9 241 0 58.2/109.7/391.1 F cornell.edu 350 128 9 240 0 63.9/164.8/4143.8 H osu.edu 75 64 249 0 10.5/23.7/115.0 128 249 0 12.7114.5126.7 F osu.edu 75 64 248 0 12/1/48.7/221.4 128 248 10 13.3132.4161.3 H ohiou.edu local 64 5 63 0 2.613.114.2 128 5 63 0 3.013.213.9 F ohiou.edu local 64 6 62 0 5.316.016.9 128 6 62 0 5.7/8.8/26.3 H aae.uiuc.edu 350 64 9 248 0 29.5/31.9/36.4 F aae.uiuc.edu 350 128 9 247 0 33.6/64.1/337.0 H usc.edu 2034 64 9 237 10 116.2/209.9/393.2 128 9 237 0 113.3/239.4/862.4 F usc.edu 2034 64 9 236 10 115.7/289.2/613.7 128 9 236 10 111/223/724 H md2.vsnl.net.in 8655 64 9 247 20 643.71659.71699.3 128 9 247 0 643/751/1654 F md2.vsnl.net.in 8655 64 9 246 20 653.31731.71945.3 128 9 246 30 656I731.81851.1 J Summary of Observations

The observations common to a regular host and a mobile host are listed below

Variations in packet size do not introduce a significant difference in the route taken, round-trip time or the number of hops.

The number of hops from a particular host remained the same most of the time unless there was a heavy and drastic change in the volume of traffic.

The number of hops are independent of the physical distance of the remote host unless the host is extremely far or very close.

There is a high difference in the round-trip time to receive responses sometimes which could be due to the traffic along the route.

The average round-trip time varies between lOms and 500ms indicating the unpredictability of traffic volume in some cases.

There is a significant packet loss rate when the hosts are far from the mobile host.

The following list of observations compares the data for the mobile host in its home network and foreign network.

The number of hops the packet travels from a remote host is the same in both the cases.

The TTL field in the packet when it arrives at the mobile host in its foreign network is always one less than the TTL value for the normal case in the home network.

There is no way to know from the Record Route that the ping program was from the mobile host in a foreign network or that the final destination is a foreign network. The packet loss is not dependent on whether the mobile host is in the home network or foreign network while issuing the ping command.

There is no significant change in round-trip time when the mobile host moves to a foreign network unless the host sending the echo response packets are in the local network.

5.2.2 Observations I1

This set of experiments involved ping requests being sent to the mobile host from remote and local hosts across the Internet. The observations based on the ping response packets are tabulated in Table 5.2.

Table 5.2: Observations of ping requests from remote hosts to mobile host

Ntwk Hosts Dist Size Hop TTL Pkt Time H/F Miles Bytes Loss% Min/Avg/Max(rns) H eng.buffalo.edu 298 64 9 241 0 62/150/562 128 9 242 0 7814261724 F eng.buffa1o.edu 298 64 9 240 10 69/917/3061 128 9 241 0 22913561445 H cornell.edu 350 128 9 241 0 71/515/1074 128 9 241 0 78/101/151 F cornell.edu 350 64 9 240 20 7511841525 128 9 240 10 67/189/514 H aae.uiuc.edu 350 64 9 56 0 28.9/30.6/32.2 F aae.uiuc.edu 350 128 9 57 3 31.4/50.3/323.6 H cisco.com 2160 64 9 0 93/96/99 128 9 NA 0 9412441682 F cisco.com 2160 64 9 NA 0 96/97/99 128 9 NA 10 102/598/1733

Summary of Observations

The data gathered from pinging the mobile host provides information similar to the case when the mobile host pings remote hosts. There is no significant difference in round-trip time to get the packets from the mobile host in a home network or foreign network.

In some cases, the TTL field in the packet arriving to the mobile host in its foreign network is less than the TTL when the mobile host is in its home network.

There is no dependencies between packet loss, number of hops and the network the mobile host is currently attached to.

In some cases, the response packet seems to come from the home agent.

There is a significant packet loss when the remote hosts pinging the mobile host are physically very far away.

5.2.3 Conclusions from the ping Test

The ping results show that the mobile IP protocol implementation is indeed transparent. In most of the cases, the record of the route taken do not indicate the mobile host has moved. There is no significant difference in any of the evaluation parameters, namely, round-trip time, packet loss and route taken introduced by the mobile host's presence in the foreign network. The round-trip time varies considerably when the hosts pinged are local hosts. In this case the extra hop to the home agent instead of direct response introduces a whole extra round-trip time almost doubling the re- sultant round-trip time. In these cases, triangular routing would be more beneficial since it would remove the latency in the route taken by the packet. A test based on this and performance evaluation follows. The round-trip time and the packet loss rate depend significantly on the route taken and the volume of traffic in the route. Though in most cases, the round-trip time when the mobile host is in a foreign network is negligibility higher than usual. The unexpectedly low time for response from outside the country could be due to lighter traffic volume and faster satellite links. In cases, when the home agent caters to several mobile hosts there could be a considerable delay due to bottlenecks at the home agent. This could happen only in the cases when all the mobile hosts the home agent supports are in foreign networks. The change in TTL when the mobile host is in its home network and foreign network could be due to the difference in TTL in the inner and outer headers of an IP-in-IP packets which we discussed in Chapter 3. If the mobile host is in a foreign network the home agent encapsulates its datagrams in IP-in-IP packets with different TTL values in the inner packet and outer header.

Thus, it is safe to conclude that the overhead measurements from the ping tests are considerably negligible in most cases. There is also no performance degradation due to the implementation of mobile IP to support mobile host's movements.

5.3 Client-Server Program for TCP Packets

This experimental setup is based on the client-server model. The client sends a random string to the server. The server reverses the string and sends it back to the client. The server process is started in the background and the server is listening on a specific port for the client's request. When it receives the request it reverses the string and sends it back to the port the client is listening on. The time taken for the client to receive a reply and the time taken for the server to process the string are measured. This client-server model is implemented when the mobile host is in its home network and when it is in its foreign network. The data collected is tabulated in Table 5.3.

The experiment is repeated with the mobile host as the client and some local or remote host as the server and with the mobile host as the server and a remote host as the client.

From the iterations it is clear that the processing time on the server side is almost a constant since it is not influenced by any other factors other than the CPU time and the length of the string. When stream sockets are used, virtual packet switched connection is used which involves a high overhead for connection establishment ini- 64

Table 5.3: Observations from the Client-Server Model. The mobile host is the client.

String Home Network Foreign Network Pillaiyarappa Server MH Server MH 3478 18366 3121 22005 3170 16477 3759 22419 2970 22754 3257 16643 3591 16486 3420 18046 3214 9011 3591 18247 3351 16456 3191 17973 C tially but is less for the subsequent packets.From the table 5.3, we see that though there seems to be a negligible increase in the time measured when the mobile host is in a foreign network, it is extremely low. This does not introduce any significant degradation in performance irrespective of whether the mobile host is in its home network or foreign network.

5.4 Performance Measurements for Routing Opti- mizations

As described in Section 4.3.4, the Mobile Policy Table is configured to help select the routing mechanism which would best optimize the path taken by the packet. From the results of the ping experiments in Section 5.2 and the tabulated observations in Table 5.4 it is clear that when the hosts which receive the ping requests are local hosts, there is a significant increase in the round-trip time between the mobile host being in its home network and the mobile host visiting a foreign network and using bidirectional routing via the home agent. This is further tested by adding an entry in the Mobile Policy Table to route packets in the local network using triangular routing. ping program is used to measure the round-trip time under both the routing mechanisms. The observations are tabulated below in Table 5.4. This illustrates the comparative reduced packet latency using triangular routing as opposed to bidirectional routing. The differences in times are considerable since the host pinged was a local host. 6 5

Table 5.4: Comparison of Bidirectional Tunneling and Triangular Routing

Routing Method Min (ms) Max (ms) Avg(ms) Bi-directional 4.7 9.7 5.1 Triangular 3.0 5.1 4.5 No Mobility 2.0 3.1 3.5

5.5 Performance while Switching Networks

This test was designed to measure the overhead and packet loss while the mobile host is switching from home network to foreign network. UDP packets are sent continuously and the mobile host switches its network. When the mobile host is the sender of the packets, the packet transmission stalls during the switch and the receiver waits for more packets. Once the switch and subsequent registration are successfully completed the packet transmission is resumed automatically. At the end of several iterations, it was observed that the packet loss rate was around 20%-30%. When the mobile host is the receiver and another correspondent host is sending the packets continuously uninterrupted, the receiver program hangs during the switch. Several iterations were run and it was found that the packet loss depends on the time taken for switching and subsequent registration with the home agent. If there is a delay at the DHCP address allocation this leads to very high percentages of packet loss.

5.6 Summary

The experiments described in this section were aimed at finding the disadvantages and the additional overhead that would be introduced by the mobile IP protocol requirements. It has been found that in most cases, the overhead measurements in terms of round-trip time or packet loss are considerably negligible due to the implementation of the mobile IP protocol. Thus, it can be confidently concluded that the mobile IP protocol offers immense flexibility in terms of supporting Internet mobility at a very low overhead cost. Chapter 6 Conclusion

The objective of this research has been to demonstrate the mobility support provided to mobile hosts leaving their static IP address in the home network to temporary care- of addresses in a foreign network. Under the existing IP protocol with no mobility support the mobile host loses its connection to the Internet when it changes its IP address. This implies that any packets sent to the mobile host at its home IP address uyould be lost. The overwhelming demand for continuous, uninterrupted network connectivity for mobile users prompted various proposals and encouraged research to support Internet mobility.

The Mobile IP protocol adopted by the Internet Engineering Task Force has been selected as the suitable standard for this implementation based on its fulfillment of the required specifications and constraints. The protocol implemented here involves no changes to the existing IP infrastructure at the backbone routers or hosts. There have been enhancements and modifications at the mobile host and the home agent with considerations for backward compatibility to include features, functionalities and components to provide mobility support. The transition from the home IP address to a foreign DHCP address is transparent and no other hosts other than the mobility support entities are aware of the mobile host's movements. There is no additional burden on the limited IPv4 address space due to the presence of mobile hosts in the network. These features support the mobile host's migrations to different networks. The design of our mobility support architecture operates without the support of foreign agents in foreign networks. This ensures the mobile hosts, the additional flexibility of moving to any network irrespective of whether foreign agent support is provided. When the mobile host moves to a different network, the home agent intercepts its packets arriving at the home network and tunnels it to the mobile host in the foreign network. The packets from the mobile host to other correspondent hosts are routed via the home agent. Thus without propogating the change in the mobile host's point of attachment, the connectivity with the hosts across the network is ensured and maintained.

The kernel modification and software enhancements at the mobile host and the home agent do not affect the normal functioning of IP protocol unless the mobility support is invoked. When the mobility support modules and daemons are started, the routing tables and ARP caches are altered to route the mobile host's packets to the correct destinations. These caches are flushed when the mobile host is in its home network.

In our network test-bed here, various experiments have been conducted to measure the performance of the network when the mobility support daemons are running. The overhead measured due to the rerouting of packets via the home agent is considerably negligible when the correspondent hosts are remote and quite high for local hosts when the mobile host is closer to the correspondent host than the home agent. This could be resolved by using triangular routing instead of bidirectional routing (via home agent) for local correspondent hosts. The packet loss at the time of switching IP addresses is around 30%. All the higher level protocols namely, TCP, UDP, FTP work normally. The transparency of the mobility is maintained by using the mobile host's home address wherever necessary and possible for packets originating at the mobile host. Though our test-bed system here involved wired hosts, the software has provisions and components to support wireless hosts. Most of the research and implementation of the mobile IP principles has been restricted to an organization. The future work could be directed to deal with implementations of a large scale model with concentration on the management issues to handle cellular networks with minimum handoff. Other quality of service parameters dealing with bandwidth, latency, error rates and security issues would also be a good area to address.

The system here could be modified suitably to enhance compatibility with IPv6 protocol which is gradually being widely used. IPv6 handles the issues of binding caches at the routers which minimises the need to route packets through the home agent every time. These caches could be updated and maintained to make suitable routing decisions at the intermediate routers thereby reducing overhead at the home agent.

To summarize ure could fairly conclude that the mobile IP system here allows the mobile hosts the freedom to switch IP addresses and networks without interrupting the connectivity with other hosts. This feature is ensured with comparitively low cost and no alterations to the existing network design or to other routers and hosts in the network. The overhead involved is also effectively low compared to flexibility provided. Bibliography

[AP95] -4. biz and M. Patterson, editors. Design and Implementation of SKIP, June 1995.

[Bha95] Pravin Bhagwat. A framework for integrating Mobile Hosts within the Internet. PhD thesis, Rutgers, The State University of New Jersey, 1995.

[BX97] Mary G. Baker and Zhao Xinhua. Flexible connectivity for mobile hosts. Technical report, Computer Science Lab, Stanford University, September 1997.

[BXCS96] Mary G. Baker, Zhao Xinhua, Stuart Chesire, and J. Stone, editors. Sup- porting Mobility in MosquitoNet, Proceedings of the USENIX Technical Conference, San Diego, CA, January 1996.

[Corn951 Douglas E. Comer. Internetworking with TCPIIP. Prentice-Hall, 3rd edition, 1995.

[Dee911 S. Deering. ICMP Router Discovery Messages. RFC 1256. Xerox PARC, September 1991.

[DG96a] Abhijit Dixit and Vipul Gupta. The design and deployment of mobility supporting network. ISPAN, Wireless and Mobile Networks, 1996.

[DG96b] Abhijit Dixit and Vipul Gupta. Mobile-ip for linux. Release note linux mobile-ip version 1.00, SUNY, Binghamton, May 1996. [Dor97] R. Dorms. Dynamic Host Configuration Protocol. RFC 2131. Bucknell Lniversity, March 1997.

[IM93] John Ioannadis and Gerald Maguire, editors. Design and Implementa- tion of a Mobile Internetworking architecture, Winter USENIX Technical Conference, 1993.

IJohl David B. Johnson. The cmu monarch project ietf mobile ipv4 implementation user's guide. Available at ftp://ftp.monarch.cs.cmu.edu/pub/monarch/mobileip/users-guide.ps.

[KA95] S. Kent and R. Atkinson. Security Architecture for the Internet Protocol. IETF, August 1995. Internet Draft. Work in Progress.

[MG98a] G. Montenegro and Vipul Gupta. Firewall support for Mobile IP. Sun hlicrosystems, Inc., January 1998. Internet Draft. Work in Progress.

[MG98b] G. Montenegro and Vipul Gupta. Sun's SKIP Firewall Traversal for Mobile IP. RFC 2356. Sun Microsystems, Inc., June 1998.

[MS94] Andrew Myles and David Skellern. Comparing four ip based mobile host protocols. Technical report, High Speed Networks Group, Macquarie Uni- versity, Australia, 1994.

[Per96a] Charles Perkins. IP Encapsulation within IP. RFC 2003. IBM, October 1996.

[Per96b] Charles Perkins. IP Mobility Support. RFC 2002. IBM, October 1996.

[PJB99] Charles Perkins and David Johnson B. Mobility support in IPv6. IETF, June 1999. Internet Draft. Work in Progress.

[Pos80] J. Postel. User Datagram Protocol. RFC 0768, August 1980.

[Riv92] R. Rivest. The MD5 Message-Digest Algorithm. RFC 1321. RSA Data Security, April 1992. [ST971 L. A. Sanchez and G. Troxel. Rapid Authentication for Mobile IP. IETF, November 1997. Internet Draft. Work in Progress.

[surl NUA Internet Surverys. How many online? Available at http://www.nua.ie/surveys/how~many~online/index.html.

[Tan961 Andrew S. Tanenbaum. Computer Networks. Prentice-Hall Inc., 3rd edition, 1996.

[Yun97] Li Yunzhou. Implementation of mobile ip within the linux kernel. Master's thesis, National University of Singapore, 1997.

[ZC97] John K. Zao and M. Condell. Use of IPSec in Mobile IP. BBN Technolo- gies, November 1997. Internet Draft. Work in progrss. Appendix A

Installation of the Mobile IP distribution

This describes the installation of MosquitoNet Mobile IP.

Linux Kernel Source Code ftp://sunsite.unc.edu/pub/Linux/kernel/v2.0 Download linux-2.0.36.tar.g~ cd /usr/src

gzip -cd linux-2.0.36.tar.g~- tar xfv -

Apply patches for mobil.ity support

Download MosquitoNet-MIP-1 .O.5 implementation cd /usr/src/linux-2.0.36 cp MosquitoNet-MIP-l.O.5/mipkernel-2.0.36.patch patch -pl i mipkernel-2.0.36.patch

Kernel Compilation make menuconfig Set configuration to enable Mobile IP protocol. Load other modules essential for Mobile IP. Enable IP forwardinglgatewaying and IP tunneling. cd /usr/include rm -rf asm linux scsi In -s /usr/src/linux/include/asm-i386 asm In -s /usr/src/linux/include/linux linux In -s /usr/src/linux/include/scsi scsi make dep make clean make bzImage Installation complete. Repeat on both home agent and mobile host until successfully installed.

Compiling user-level daemons

Change directory to where the daemon code is. make clean; make all This will build the mobile host daemon (mhd) and home agent daemon (had). mv had /sbin on home agent mv mhd Isbin on mobile host h$ove all files to respective / directory on the computer. Repeat for both the computers.

Operations on home agent

Make a had.conf file with information about IP addresses of home agent and mobile host, netmasks and mobility binding details of mobile host. Bring up the virtual interface with ifconfig vif up netmask broadcast Invoke home agent daemon with /sbin/had -d -v Operations on mobile host

Make a mhd.conj file for information about home agent IP address, and security binding details shared with the home agent. Make a mpt.conf to configure the policies to build the Mobile Policy Table. The mobile host daemon is invoked with a mip start To kick start the mobile host daemon when it has moved mip restart or mip update

System messages

The system messages for informational purposes and debugging can be read from /var/log/messages* files. Appendix B

Routing Tables on Home Agent No Mobile Host Support

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface 132.235.15.0 * 255.255.255.0 U 0 0 463 ethO 127.0.0.0 * 255.0.0.0 U 0 0 30 lo default gatewayl5.ece.o 0.0.0.0 UG 0 0 355 ethO

With Mobility Support

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface mobi1e.ece.o * 255.255.255.255 UH 0 0 1 vif 132.235.15.0 * 255.255.255.0 U 0 0 463 ethO 127.0.0.0 * 255.0.0.0 L 0 0 30 lo default gatewayl5.ece.o 0.0.0.0 UG 0 0 355 ethO Routing Tables on Mobile Host No Mobility Support

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface 132.235.15.0 * 255.255.255.0 U 0 0 4 ethO 127.0.0.0 * 255.0.0.0 U 0 0 13 lo default gatewayl5.ece.o 0.0.0.0 UG 0 0 355 ethO

With Mobility Support

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface 132.235.18.0 * 255.255.255.0 U 0 0 69 ethO 127.0.0.0 * 255.0.0.0 U 0 0 13 lo Network Interface On Home Agent

With Mobility Support

lo Link encap:Local Loopback inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0 UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:l RX packets:7509 errors:O dropped:O overruns:O frame:O TX packets:7509 errors:O dropped:O 0verruns:O carrier:O collisions:0 vif Link encap:AMPR NET/ROM HWaddr inet addr:132.235.15.120 Bcast:132.235.15.255 Mask:255.255.255.0 UP BROADCAST RUNNING NOARP MULTICAST MTU:1460 Metric:l RX packets:O errors:O dropped:O overruns:O frame:O TX packets:56309 errors:O dropped:O overruns:O carrier:O collisions:0 ethO Link encap:Ethernet HWaddr 00:AA:00:55:80:F7 inet addr:132.235.15.120 Bcast:132.235.15.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:l RX packets:12634864 errors:O dropped:O overruns:O frame:O TX packets:86177 errors:O dropped:O overruns:O carrier:O collisions:238 1nterrupt:lO Base address:Ox300 Network Interface On Mobile Host With Mobility Support

lo Link encap:Local Loopback inet addr:127.0.0.1 Bcast:127.255.255.255 hIask:255.0.0.0 UP BROADCAST LOOPBACK RUNNING VTU:3584 Metric:l RX packets:32 errors:O dropped:O overruns:O frame:O TX packets:32 errors:O dropped:O overruns:O carrier:O collisions:O vif Link encap:AMPR NET/ROM HWaddr inet addr:132.235.15.121 Bcast:132.235.15.255 Mask:255.255.255.0 UP BROADCAST RUNNING NOARP MULTICAST MTU:1460 Metric:l RX packets:33924 errors:O dropped:O overruns:O frame:O TX packets:O errors:O dropped:O overruns:O carrier:O co1lisions:O ethO Link encap:Ethernet HWaddr 00:10:5A:l3:F4:DD inet addr:132.235.18.133 Bcast:132.235.18.255 Mask:255.255.255.0 UP BROADCAST NOTRAILERS RUNNING MULTICAST hITU:1500 Metric:l RX packets:5735001 errors:O dropped:O overruns:O frame:O TX packets:64552 errors:O dropped:O overruns:O carrier:O collisions:82 1nterrupt:lO Base address:Ox300 No Mobility Support lo Link encap:Local Loopback inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0 UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:l RX packets:32 errors:O dropped:O overruns:O frame:O TX packets:32 errors:O dropped:O overruns:O carrier:O collisions:O ethO Link encap:Ethernet HWaddr 00:10:5A:13:F4:DD inet addr:132.235.15.121 Bcast:132.235.15.255 Mask:255.255.255.0 UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:l RX packets:57887811 errors:O dropped:O overruns:O frame:O TX packets:65232 errors:O dropped:O 0verruns:O carrier:O collisions:82 1nterrupt:lO Base address:Ox300 ARP cache On Mobile Host

No Mobility Support

Address HWtype HWaddress Flags Mask Iface homer.ece.ohiou.edu ether 08:00:20:21:CE:08 C ethO mobil2.ece.ohiou.edu ether 00:AA:00:55:80:F7 C ethO

With Mobility Support

Address HWtype HWaddress Flags Mask Iface iceman.ent.ohiou.edu ether 00:10:5A:19:29:54 C ethO 132.235.18.254 ether 00:60:70:A3:CO:22 C ethO 132.235.18.254 ether 00:60:70:A3:CO:22 C ethO ARP cache On Home Agent No Mobility Support

Address HWtype HWaddress Flags Mask Iface homer.ece.ohiou.edu ether 08:00:20:21:CE:08 C ethO gatewayl5.ece.ohiou.edu ether 00:60:70:A3:CO:22 C ethO mobile.ece.ohiou.edu ether 00:10:5A:13:F4:DD C ethO

With Mobility Support

Address HWtype HWaddress Flags Mask Iface homer.ece.ohiou.edu ether 08:00:20:21:CE:08 C ethO gatewayl5.ece.ohiou.edu ether 00:60:70:A3:CO:22 C ethO mobile.ece.ohiou.edu ether 00:AA:00:55:80:F7 CMP ethO Appendix C

Sample results of ping command ping packets received from other hosts Local host: bobcat.ent.ohiou.edu

When the mobile host is in its foreign subnet and sends ping requests to host local to the network (bobcat. ent. ohiou. edu) PING bobcat.ent.ohiou.edu (132.235.17.1): 128 data bytes 136 bytes from 132.235.17.1: icmpseq=O ttl=254 time=5.3 ms

RR: 132.235.18.155 132.235.17.254 bobcat.ent.ohiou.edu (132.235.17.1) mobil2.ece.ohiou.edu (132.235.15.120) mobile (132.235.15.121)

- bobcat.ent.ohiou.edu ping statistics - 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 4.915.719.3 ms When the mobile host is in its home subnet and sends ping requests to host local to the network (bobcat.ent. ohiou. edu) PING bobcat.ent.ohiou.edu (132.235.17.1): 128 data bytes 136 bytes from 132.235.17.1: icmpseq=O ttl=255 time=3.7 ms

RR: mobile (132.235.15.121) 132.235.17.254 bobcat .ent.ohiou.edu (132.235.17.1) mobile (132.235.15.121)

- bobcat.ent.ohiou.edu ping statistics - 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 2.413.014.4 ms Remote host - usc.edu

When the mobile host is in foreign subnet and sends ping requests to a remote host (usc. edu) PING usc.edu (128.125.253.136): 128 data bytes 136 bytes from 128.125.253.136: icmpseq=O ttl=236 time=125.lms

RR: 132.235.18.155 ohu-ath3.oar.net (199.18.18.6) ath3-atml-0sl.athens.oar.net (199.18.18.10) athl-atml-0.athens.oar.net (199.18.202.81)) oeb3-atm6-0.columbus.oar.net (199.18.202.13) s0.oarnet.bbnplanet.net (4.0.224.254) fl-1-0.clevelandl-crl.bbnplanet.net(4.0.56.18) h2-0.clevelandl-br2.bbnplanet.net (4.0.2.13) hll-0-0.nycl-br2.bbnplanet.net(4.0.2.177)

- usc.edu ping statistics - 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 121.0/193.6/656.5 ms When the mobile host is in its home subnet and sends ping requests to a remote host (USC.edu) PING usc.edu(128.125.19.136): 128 data bytes 136 bytes from 128.125.19.136: icmpseq=O ttl=237 time=137.6 ms

RR: mobile (132.235.15.121) ohu-ath3.oar.net (199.18.18.6) ath3-atml-0sl .athens.oar.net (199.18.18.10) athl-atml-O.at,hens.oar.net (199.18.202.81) oeb3-atm6-0.columbus.oar.net (199.18.202.13) s0.oarnet.bbnplanet.net (4.0.224.254) fl-l-0.clevelandl-crl.bbnplanet.net(4.0.56.18) h2-0.clevelandl-br2.bbnplanet.net(4.0.2.13) h3-0-0.nycl-br2.bbnplanet.net(4.0.2.181)

- usc.edu ping statistics - 10 packets transmitted, 9 packets received, 10% packet loss round-trip min/avg/max = 116.2/243.1/670.3 ms Result of mobile host's response to ping Remote host - aa6.aae.uiuc.edu

When the mobile host is in a foreign subnet and sends a ping packet in response to a request from a remote host (aa6. aae.uiuc. edu) PIXG mobile.ece.ohiou.edu (132.235.15.121): 56 data bytes 64 bytes from 132.235.15.121: icmpseq=O ttl=56 time=36.1 ms

RR: aa6.aae.uiuc.edu (128.174.132.57) t-nodel-12.gw.uiuc.edu (128.174.1.230) t-exit l.gw.uiuc.edu (128.174.0.226) world.gw.uiuc.edu (206.220.243.70) tlp3-atml-0.toledo.oar.net(199.18.202.53) athl-atm2-0sl.athens.oar.net (199.18.18.9) ath3-fasteth0-0.athens.oar.net(199.18.18.5) 132.235.17.254 mobil2.ece.ohiou.edu (132.235.15.120)

- mobile.ece.ohiou.edu ping statistics - 33 packets transmitted, 32 packets received, 3% packet loss round-trip min/avg/max = 31.4/50.3/323.6 ms When the mobile host is in its home subnet and sends a ping packet in response to a request from a remote host (aa6.aae.uiuc.edu) PING mobile.ece.ohiou.edu (132.235.15.121) : 56 data bytes 64 bytes from 132.235.15.121: icmpseq=O ttl=56 time=30.3 ms

RR: aa6.aae.uiuc.edu (128.174.132.57) t-nodel-12.gw.uiuc.edu (128.174.1.230) t-exitl.g\nr.uiuc.edu (128.174.0.226) world.gw.uiuc.edu (206.220.243.70) tlp3-atml-0.toledo.oar.net (199.18.202.53) athl-atm2-0sl.athens.oar.net (199.18.18.9) ath3-fasteth0-0.athens.oar.net(199.18.18.5) 132.235.17.254 mobile.ece.ohiou.edu (132.235.15.121)

-- mobile.ece.ohiou.edu ping statistics - 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 28.9/30.6/32.2 ms