Mobile IP Adaption

Mobile IP [6] is a good solution to supporting seamless connection for mobile hosts while roaming. Mobile IP works by allowing a mobile node (MN) to be associated with two IP addresses: a home address and a dynamic care-of address. The home address is fixed, and the care-of address changes at each new point of attachment to the Internet. The home IP address assigned to the mobile client makes it logically appear as if the mobile node is attached to its home network. The care-of address identifies MN’s current topological location. For a correspondent node (CN), the MN seems to be attached to its home network all the time.

As shown in Figure 5.6, two mobility agents are deployed by mobile IP. Home Agent (HA) locates in a home network to receive traffic destined to MN’s home IP address when MN is not physically attached to the home network. When MN attaches to a foreign network, HA tunnels traffic to a Foreign Agent (FA) using MN’s current care-of address like MN1 in Figure 5.6. Whenever MN moves its point of attachment, it registers a new care-of address with its Home Agent.

HAs and FAs regularly broadcast agent advertisements. When an MN receives an agent advertisement, it can obtain an IP address. The MN may also broadcast an agent solicitation that will be answered by any FA that receives it. Thus, agent advertisement procedure allows for the detection of mobility agents, lets the MN determine the network number and status of

Payload

Figure 5.7: An example of ping-pong routing for an MN attaches to a hierarchical mobile network.

its link to the Internet, and identifies whether the agent is a HA or a FA. Once an MN receives a care-of address, a registration process is used to inform the HA of the care-of address. The registration allows the HA to update its routing table to include the mobile’s home address, current care-of address, and a registration lifetime.

Mobile IP provides another alternative to let MN have a co-located care-of address without support of FAs. In this case, MN like MN2 in Figure 5.6 needs to detect movement by sending router solicitation periodically. Once it finds it moves into a new network, it needs to acquire an co-located care-of address, which can be obtained by running DHCP client. The registration process will also be triggered after MN having an address. Afterwards, HA tunnels traffic destined to MN to its co-located care-of address directly.

We can apply Mobile IP to solve roaming problems when an MN roams into a MANET.

However, it may cause polygon or ping-pong routing when MNs roam into a hierarchical mobile network. As shown in Figure 5.7, an MN attaches to MR3, which is in a hierarchial NEMO with ancestor mobile routers MR2 and MR1. When CN sends a packet to MN, the packet will be routed to MN’s home network and be intercepted by^HAMN. ^HAMN checks its routing table and tunnels the packet to MN’s care-of address, which is MR3’s home address.

The packet then will be tunneled to^HAM

R 3,^HAM

R 2,^HAM

R 1in order. At last, the packet will be tunneled to MR1. MR1 decapsulates the packets and forward to MR2, and then to MR3 and MN similarly. This problem can be solved by Reverse Routing Header [40], which records the path from MN to CN. Therefore, CN can sends packets to MN by proceeding the reverse routing path from MN to CN.

5.3.1 Problems of roaming in public networks

There is a problem for LFNs in a NEMO. LFNs not like MNs have only one address. While CN sends a packet destined to an LFN, the packet will be routed to MR’s home network.

Unfortunately, LFN has left there already, and the HA of MR does not have any record for the LFN, either. In the specification of Mobile IP, LFN could be treated as an MN, so HA will have records of all LFN in the NEMO. However, each LFN in the NEMO needs to send registration request as a normal MN does whenever the NEMO roams into a new network.

This may cause huge overhead and HA also needs to store lots same record. Thus we propose a method to reduce signal overhead.

The proposed method makes MR to register for all LFNs in its subnetwork by sending its network prefix to it HA only. As a result, HA needs to store only one more record for each MR. Whenever the HA receives a packet destined to any node belongs to a subnetwork with the same prefix it records in its routing table, it just tunnels the packet to the care-of address of MR as recorded in its routing table.

5.3.2 Problems of roaming in private networks

Although Mobile IP [6] can maintain seamless connection for MNs while roaming, mobile nodes are limited to roam in public networks. One reason is that HAs can not tunnel packets to a private IP address. Another reason is that the original IP-in-IP tunnels hide port information, making Network Address Translation (NAT) servers unable to do the translation. However, it is normal to configure a MANET as a private network like Figure 5.1, and it will cause problem if an MN roams into a private MANET. To maintain correct tunnels to mobile hosts in private networks, we adopt a mechanism called NAT traversal [19]. It applies UDP tunneling, which encapsulates an extra UDP/IP header outside the IP payload, to provide port information to

GPRS Core

(2)Create entries for MN

(3)Create entries for NAT2

(4)Create binding

Src: IPMN_PV2 Src: PortMN

Dst: IPHA_PB1 Dst: PortHA

IP UDP Home Agent: IPHA_PB1

Home IP: IPMN_PB1

CCoA: IPMN_PV2

MIP Registration_Request packet (MIP RR)

Src: IPCN_PB3

Src: IPHA_PB1 Src: PortHA

Dst: IPNAT1_PB2Dst: PortNAT1

IP UDP IP Payload

Packet destined to MN

Dst: IPMN_PB1

Src: IPMN_PV2 Src: PortMN

Dst: IPHA_PB1 Dst: PortHA

IP UDP IP Payload

(5)Encapsulation by HA

(6)After NAT1

Src: IPCN_PB3

Src: IPHA_PB1 Src: PortHA

Dst: IPNAT2_PV1Dst: PortNAT2

IP UDP IP Payload

Packet destined to MN

Dst: IPMN_PB1

Src: IPCN_PB3

Src: IPHA_PB1 Src: PortHA

Dst: IPMN_PV2 Dst: PortMN

IP UDP IP Payload

Packet destined to MN

Dst: IPMN_PB1

(8)Encapsulation by MN

Intetnet

Figure 5.8: Operations of NAT traversal.

NAT servers.

Figure 5.8 shows how NAT traversal works. There are four NAT servers and two gateways (one using GPRS and one using PHS). NAT1 is the NAT server in the GPRS core network, to which NAT2 is connected, and NAT4 is the server in the PHS network, to which NAT3 is connected. ^IPAPB/^IPAPV denotes the IP address of a host A when it is in a public/private domain. For example, the GPRS gateway has two interfaces: ^IPNAT2PV2 on the low-tier network and^IPNAT2PV1 on the high-tier GPRS network.

Consider a mobile node MN, which has a permanent address^IPMN PB1and a home agent (HA) with an address ^IPHAPB1, in a public network PB1. Suppose that MN moves into a MANET and obtains a CCoA ^IPMN PV2 assigned by the gateway NAT2. MN will send a registration request to inform HA its new care-of address via its serving gateway (step 1).

When forwarding the request, NAT1 and NAT2 will update their transition tables (steps 2 and 3). When HA receives this registration request, it compares its source address against the CCoA that it claims. If they are not compatible, HA considers MN as inside a private network

and registers^IPNAT1PB as MN’s care-of address (step 4). Later on, for each packet from CN destined to MN, an extra IP/UDP header will be added (step 5). Both NAT1 and NAT2 will translate the packet according to their DNAT transition rules (steps 6 and 7). Similarly, whenever MN wants to send a packet, it also encapsulates an IP/UDP header (step 8). The SNAT transition rules will then be used to forward the packet to HA (we omit the details here).

On receipt of the packet, HA then decapsulates the IP/UDP header and forwards the packet to CN.

When MN roams into a different sub-MANET, we allow it to keep its care-of address.

However, MN has to re-register with HA (this is not required in typical Mobile IP); otherwise, HA and the NAT servers will not have correct transition rules. For example, when MN moves to NAT3, a re-registration will be sent to HA (step 9).