TCP/IP-II:Mobile IP.

Mobile IP

• The Mobile IP protocol allows location-independent routing of IP datagrams on the Internet.
• Each mobile node is identified by its home address disregarding its current location in the Internet. While away from its home network, a mobile node is associated with a care-of address which identifies its current location and its home address is associated with the local endpoint of a tunnel to its home agent.
• Mobile IP specifies how a mobile node registers with its home agent and how the home agent routes datagrams to the mobile node through the tunnel.
• Mobile IP provides an efficient, scalable mechanism for roaming within the Internet.

Using Mobile IP, nodes may change their point-of-attachment to the Internet without changing their home IP address.

• Mobile IP allows portable devices called mobile hosts (MHs) to roam from one area to another.

A common analogy to understand Mobile IP is that when someone moves his residence from one location to another. Person moves from Boston to New York. Person drops off new mailing address to New York post office. New York post office notifies Boston post office of new mailing address. When Boston post office receives mail for person it knows to forward mail to person's New York address.

The below figure describes the mobile hosts routing

Mobile IP operates as follows:-

When a correspondent host (CH) wants to send a packet to MH, the CH transmits the standard IP packet with its address as the source IP address and MH’s address as destination IP address.

This packet will be intercepted by the mobile host’s router called home agent (HA), which keeps track of the current location of the MH. The HA manages all MHs in its home network that use the same address prefix

If the MH is located in the home network, the HA simply forwards the packet to its home network.

When an MH moves to a foreign network, the MH obtains a care of address from the foreign agent (FA) and registers the new address with its HA. The care-of-address reflects the MH’s current location and is typically the address of FA.

Once the HA knows the care-of-address of the MH, the HA can forward the registration packet to the MH via the FA.

To transmit a packet by HA to MH directly when MH is in foreign network, instead of using FA, tunneling mechanisms is used. It has two addresses,

· Destination address of the other end of the tunnel (FA) and Final destination MH.

NAT (Network Address Translation or Network Address Translator)

NAT is the translation of an Internet Protocol address (IP address) used within one

network to a different IP address known within another network.

One network is designated the inside network and the other is the outside.

Typically, a company maps its local inside network addresses to one or more global outside IP addresses and unmaps the global IP addresses on incoming packets back into local IP addresses.

This helps ensure security since each outgoing or incoming request must go through a translation process that also offers the opportunity to qualify or authenticate the request or match it to a previous request.

NAT also conserves on the number of global IP addresses that a company needs and it lets the company use a single IP address in its communication with the world.

NAT is included as part of a router and is often part of a corporate firewall.

Network administrators create a NAT table that does the global-to-local and local-to- global IP address mapping.

NAT can be statically defined or it can be set up to dynamically translate from and to a pool of IP addresses.

NAT lets an administrator to create tables that map:

A local IP address to one global IP address statically

A local IP address to any of a rotating pool of global IP addresses that a company may have a local IP address plus a particular TCP port to a global IP address or one in a pool of them

A global IP address to any of a pool of local IP addresses on a round-robin basis

DHCP (Dynamic Host Configuration Protocol)

DHCP protocol is used to assign IP addresses to hosts or workstations on the network.

Usually a DHCP server on the network performs this function. Basically it "leases" out address for specific times to the various hosts.

If a host does not use a given address for some period of time, that IP address can then be assigned to another machine by the DHCP server. When assignments are made or changed, the DHCP server must update the information in the DNS server.

As with BOOTP, DHCP uses the machine's or NIC ethernet (MAC) or hardware address to determine IP address assignments. The DHCP protocol is built on BOOTP and replaces BOOTP.

DHCP Lease Stages

1. Lease Request - The client sends a broadcast requesting an IP address

2. Lease Offer - The server sends the above information and marks the offered address as unavailable. The message sent is a DHCPOFFER broadcast message.

3. Lease Acceptance - The first offer received by the client is accepted. The acceptance is sent from the client as a broadcast (DHCPREQUEST message) including the IP address of the DNS server that sent the accepted offer. Other DHCP servers retract their offers and mark the offered address as available and the accepted address as unavailable.

4. Server lease acknowledgement - The server sends a DHCPACK or a DHCPNACK if an unavailable address was requested.

DHCP discover message - The initial broadcast sent by the client to obtain a DHCP lease. It contains the client MAC address and computer name. This is a broadcast using 255.255.255.255 as the destination address and 0.0.0.0 as the source address.

Dynamic Host Configuration Protocol (DHCP) is a network protocol that enables a server to automatically assign an IP address to a computer from a defined range of numbers (i.e., a scope) configured for a given network.

DHCP assigns an IP address when a system is started, for example:

1. A user turns on a computer with a DHCP client.

2. The client computer sends a broadcast request (called a DISCOVER or DHCPDISCOVER), looking for a DHCP server to answer.

3. The router directs the DISCOVER packet to the correct DHCP server.

4. The server receives the DISCOVER packet. Based on availability and usage policies set on the server, the server determines an appropriate address (if any) to give to the client. The server then temporarily reserves that address for the client and sends back to the client an OFFER (or DHCPOFFER) packet, with that address information. The server also configures the client's DNS servers, WINS servers, NTP servers, and sometimes other services as well.

5. The client sends a REQUEST (or DHCPREQUEST) packet, letting the server know that it intends to use the address.

6. The server sends an ACK (or DHCPACK) packet, confirming that the client has a been given a lease on the address for a server-specified period of time.

When a computer uses a static IP address, it means that the computer is manually configured to use a specific IP address. One problem with static assignment, which can result from user error or inattention to detail, occurs when two computers are configured with the same IP address. This creates a conflict that results in loss of service. Using DHCP to dynamically assign IP addresses minimizes these conflicts.

Figure 1

In figure 1, a new client that just joined the network, needs an IP address. Since it does not know the DHCP server's location, the client broadcasts (step 1) a DHCPDISCOVER message on the local network. The message packet contains a hardware identifier (usually the MAC address), the source port (68), the destination IP (255.255.255.255), destination port (67), and a randomly generated transaction id. Optionally the client can specify the IP address it wants and the lease duration in the message. Once the DHCP relay receives the broadcasted message, it fills in the "giaddr" field of the packet with the gateway IP address of

10.1.2.9 . This piece of information is critical because the DHCP Server needs it to determine which subnet the client is on and thus which IP address to allocate to the client. Afterwards the DHCPDISCOVER message is relayed to the DHCP Server via unicast (step 2). A unicast, instead of a broadcast, is sufficient because the DHCP relay knows the exact location of the DHCP server. For this same reason, the DHCP relay does not allow the other network segment, 10.1.1.X, to receive the message.

Once the DHCP server receives the DHCPDISCOVER request, it allocates an IP address, marks it as taken, and then broadcasts a DHCPOFFER message back to the requesting client. This message packet contains the DHCP server's IP address, the client's hardware identifier, the same transaction id, and the IP address allocated for the client. Optionally, the message

may also contain the lease time, subnet mask, default TTL, default router(s), and numerous other parameters.

Figure 2

In figure 2, the DHCP server allocates new IP address 10.1.2.3 for the client and broadcasts a DHCPOFFER message to its network (step 3). When the DHCP relay sees the DHCPOFFER broadcast, it relays the broadcast to the 10.1.2.X network and only that network (step 4). Once the new client sees the DHCPOFFER message, it accepts the IP address (step 5) and prepares a confirmation message to the DHCP server with a DHCPREQUEST packet. Please note that the client does not have to accept this IP address, in which case it will not send a DHCPREQUEST message. If multiple DHCP servers sends out a DHCPOFFER, the client can choose which one to accept. If for some reason, the DHCPOFFER message fails to ever arrive, the client will rebroadcast the DHCPDISCOVER message.

Figure 3

If the client included optional information in the initial DHCPDISCOVER message, it must include that same information in the subsequent DHCPREQUEST message. In step 6 of figure 3, the new client confirms it wants the IP address 10.1.2.3 by broadcasting a DHCPREQUEST to the DHCP server. Once the DHCP Server receives this message (with help again from the DHCP Relay), it first ensures that it is the intended target - because the client could be responding to another DHCP Server. If this DHCP server is not the intended target, then it knows some other DHCP server is handling this client. So this DHCP server can discard any previously allocated IP address for that client. If this DHCP Server is the intended recipient, then it has to verify the optional parameters that it specified in the previous DHCPOFFER message to this client, are still valid. Assuming everything is fine up to this point, the DHCP Server sends a DHCPACK broadcast (step 8) to tell the client that its new IP address can now officially be used. However, if something is wrong, then a DHCPNACK is broadcasted instead. Either way, a DHCPACK or DHCPNACK will be the final message sent by the DHCP server in the dynamic IP address allocation sequence..

Assuming it receives the DHCPACK relayed by the router (step 9), the client is encouraged to verify no other hosts has the same IP address. This is usually accomplished through a simple ARP probe. Any response to the probe means that another client is already using the IP address. In such a situation, the client must send a DHCPDECLINE message to the DHCP server. Afterwards the client will then need to restart this whole process beginning with DHCPDISCOVER phase. In most cases, there's no response to the client's ARP probe. This means the client can go ahead and use the allocated IP address along with any other optional information stored in the message packet.

If the client got a DHCPNAK instead of DHCPACK, then it has no choice but to restart everything from the very beginning i.e. the DHCPDISCOVER stage. Finally, if the client doesn't receive any DHCPACK or DHCPNAK message after a certain period of time, then it rebroadcasts the DHCPREQUEST message.