Unit – III

UNIT – III - MOBILE NETWORK LAYER

MOBILE IP

Goals
Using a mobile computer in the Internet

Problem
Mobile Computer will not receive a single packet as soon as it leaves the home network.
In the Internet, A host sends an IP packet with the header containing a destination
address besides other fields. The destination address not only determines the receiver of
the packet, but also the physical subnet of the receiver.

Requirement
A host needs a so-called topologically correct address.

Quick 'Solutions'

New Address
One might think of a quick solution to this problem by assigning the computer a
new, topologically correct IP address as it moves to a new location.
Drawback
1. It is almost impossible to find a (mobile) host in the Internet which has just
changed its address. Especially the domain name system (DNS) needs some time
before it update its internal tables necessary for the mapping of a logical name to
an IP address.
2. A TCP connection cannot survive any address change. Breaking TCP connections
is not an option, using programs like telnet would be impossible.
3. The mobile node would have to notify all communication partners about the new
address.

Creation of Specific Routes

Another approach is the creation of specific routes to the mobile node.
Drawback
1. It is theoretically possible to change all routing tables all over the world to create
specific routes to a mobile node; this does not scale at all with the number of
nodes in the Internet.
2. Routers are built for extremely fast forwarding, but not for fast updates of routing
tables.
3. No service provider or system administrator would allow changes to the routing
tables, probably sacrificing stability, just for the mobility of individual users.

Page 1
Unit – III

Requirements
Several requirements accompanied the development of the standard:

Compatibility: A new standard cannot require changes for applications or network

protocols already in use.
Mobile IP has to remain compatible to all lower layers used for the standard non-
mobile IP.
Mobile IP has to use the same interfaces and mechanisms to access the lower
layers as IP does.
Mobile IP has to ensure that users can still access all the other servers and systems
in the Internet. But that also implies using the same address format and routing
mechanisms.

Transparency: Mobility should remain 'invisible' for many higher layer protocols arid
applications.
Besides maybe noticing a lower bandwidth and some interruption in service,
higher layers should continue to work even if the mobile computer changed its point of
attachment to the network.
The only effects of mobility should be a higher delay and lower bandwidth.
There are some applications for which it is better to be 'mobility aware'. Examples
are cost-based routing or video compression.

Scalability and efficiency: Introducing a new mechanism into the Internet must not
jeopardize the efficiency of the network.
Special care has to be taken considering the lower bandwidth of wireless links.

Security: Mobility poses many security problems. A minimum requirement is the

authentication of all messages related to the management of Mobile IP.
The IP layer can only guarantee that the IP address of the receiver is correct.
There are no ways of preventing faked IP addresses or other attacks.
The goal of a mobile IP can be summarized as 'supporting end-system mobility
while maintaining scalability, efficiency, and compatibility in all respects with existing
applications and Internet protocols'.

Page 2
Unit – III

Entities and terminology

Mobile node (MN): A mobile node is an end-system or router that can change its point
of attachment to the Internet using mobile IP. The MN keeps its IP address and can
continuously communicate with any other system in the Internet as long as link-layer
connectivity is given.

(CN): At least one partner is needed for communication. In the following the CN
represents this partner for the MN. The CN can be a fixed or mobile node.

Home network: The home network is the subnet the MN belongs to with respect to its IP
address. Within the home network no mobile IP support is needed.

Foreign network: The foreign network is the current subnet the MN visits and which is
not the home network.

Foreign agent (FA): The FA can provide several-services to the MN during its visit in
the foreign network. FAs can also provide security services for they belong to the foreign
network as opposed to the MN only visiting.
Typically, an FA is implemented on a router for the subnet the MN attaches to.

Care-of address (COA): The COA defines the current location of the MN from an IP
point of view. All IP packets sent to the MN are delivered to the COA, not directly to the
IP address of the MN.

Foreign agent COA: The COA could be located at the FA, i.e., the COA is an IP address
of the FA. Thus the FA is the tunnel end-point and forwards packets to the MN. Many
MN using the FA can share this COA as common COA.

Co-located COA: The COA is called co-located if the MN temporarily acquired an

additional IP address which acts as COA.

Home agent (HA): The HA provides several services for the MN and is located in the
home network. The HA maintains a location registry, i.e., it is informed of the MN's
location by the current COA.
Three alternatives for the implementation of an HA exist.
1. The HA can be implemented on a router that is responsible for the home network.
This is obviously the best position, because without optimizations to mobile IP,
all packets for the MN have to go through the router anyway.
2. If changing the router's software is not possible, the HA could also be
implemented on an arbitrary node in the subnet. A disadvantage of this solution is
the double crossing of the router by the packet if the MN is in a foreign network.
A packet for the MN comes in via the router; the HA sends it through the tunnel
which again crosses the router.
3. Finally, a home network is not necessary at all. The HA could be again on the
'router' but this time only acting as a manager for MNs belonging to a virtual
home network. All MNs are always in a foreign network with this solution.

Page 3
Unit – III

IP packet delivery

Figure Packet delivery to and from the mobile node

1. A correspondent node CN wants to send an IP packet to the MN. CN does not

need to know anything about the MN's current location and sends the packet as
usual to the IP address of.
2. The Internet, not having information on the current location of MN, routes the
packet to the router responsible for the home network of MN. This is done using
the standard routing mechanisms of the Internet.
3. The HA now intercepts the packet, knowing that MN is currently not in its home
network. Thus, the packet is not forwarded into the subnet as usual, but
encapsulated and tunnelled to the COA. This is done by putting a new header in
front of the old IP header showing the COA as new destination and HA as source
of the encapsulated packet.
4. The foreign agent now decapsulates the packet, i.e., removes the additional
header, and forwards the original packet with CN as source and MN as destination
to the MN.
5. Again, for the MN mobility is not visible. It receives the packet with the same
sender and receiver address as it would have done in the home network.

Page 4
Unit – III

Agent advertisement and discovery

Foreign agents and home agents advertise their presence periodically using
special agent advertisement messages. These advertisement messages can be seen as a
beacon broadcast into the subnet.
For these advertisements Internet control message protocol (ICMP) messages
according are used with some mobility extensions.
Routers in the fixed network implementing this standard also advertise their
routing service periodically to the attached links.

Packet Format

Figure 9.3 Agent advertisement packet

The upper part represents the ICMP packet while the lower part is the extension needed
for mobility.
The TTL field of the IP packet is set to 1 for all advertisements to avoid forwarding of
advertisements.
The IP destination address according to standard router advertisements can be either set
to 224.0.0.1, which is the multicast address for all systems on a link or to the broadcast
address 255.255.255.255.

Basic ICMP
The type is set to 9
The code can be 0, if the agent also routes traffic from non-mobile nodes, or 16, if it does
not route anything other than mobile traffic.
The number of addresses advertised with this packet is in #addresses
The addresses themselves follow.
Lifetime denotes the length of time this advertisement is valid.
Preference levels for each address help a node to choose the router that is the most eager
one to get a new node.

Extension for mobility

Type is set to 16

Page 5
Unit – III

Length depends on the number of COAs provided with the message and equals 6 +
4*(number of addresses).
The total number of advertisements sent since initialization in the sequence number.
The registration lifetime the agent can specify the maximum lifetime in seconds a node
can request

Characteristics of an agent
The R bit (registration) shows, if a registration with this agent is required rather than
using a co-located COA at the MN.
If the agent is currently too busy to accept new registrations it can set the B bit.
If the agent offers services as a home agent (H) or foreign agent (F) on the link where
the advertisement has been sent.
Bits M and G specify the method of encapsulation used for the tunnel
M can specify minimal encapsulation
G specifies generic routing encapsulation.
The V bit specifies the use of header compression.

Page 6
Unit – III

Registration
After having received a COA, the MN has to register with the HA.
The main purpose of the registration is to inform the HA of the current location
for correct forwarding of packets.

COS is at the Foreign Agent

1. The MN sends its registration request containing the COA to the FA

2. FA forwards the request to the HA.
3. The HA now sets up a mobility binding containing the mobile node's home IP
address and the current COA.
Additionally, the mobility binding contains the lifetime of the registration which
is negotiated during the registration process.
An MN should reregister before expiration.
This mechanism is necessary to avoid mobility bindings which are not used
anymore.
4. After setting up the mobility binding, the HA sends a reply message back to the
FA
5. FA forwards Reply to the MN.

COA is co-located

The MN sends the request directly to the HA and vice versa.

This, by the way, is also the registration procedure for MNs returning home into

Page 7
Unit – III

their home network.

Here they also register directly with the HA.

UDP
For registration requests UDP packets are used.
The IP source address of the packet is set to the interface address of the MN, the
IP destination address is that of the FA or HA (depending on the location of the COA).
The UDP destination port is set to 434.
UDP is used for reasons of low overhead and better performance compared to
TCP in wireless environments.

Page 8
Unit – III

Tunnelling and encapsulation

Tunnel
A tunnel establishes a virtual pipe for data packets between a tunnel entry and a
tunnel endpoint. Packets entering a tunnel are forwarded inside the tunnel and leave the
tunnel unchanged.

Encapsulation and Decapsulation

Encapsulation is the mechanism of taking a packet consisting of packet header
and data and putting it into the data part of a new packet.
The reverse operation, taking a packet out of the data part of another packet, is
called Decapsulation.
Encapsulation and decapsulation are the operations typically performed when a
packet is transferred from a higher protocol layer to a lower layer or from a lower to a
higher layer respectively.

IP Encapsulation

Figure IP encapsulation
The HA takes the original packet with the MN as destination, puts it into the data
part of a new packet and sets the new IP header in such a way that the packet is routed to
the COA.
An inner header which can be identical to the original header as this is the case for
IP-in-IP encapsulation, or the inner header can be computed during encapsulation.

IP-in-IP encapsulation
Mandatory for mobile IP is IP-in-IP encapsulation

The fields of the outer header are set as follows.

The version field is 4 for IP version 4

Page 9
Unit – III

The Internet header length (IHL) denotes the length of the outer header in 32 bit words.
TOS is just copied from the inner header, the length field covers the complete
encapsulated packet.
The fields up to TTL have no special meaning for mobile IP and are set according to
RFC 791.
TTL must be high enough so the packet can reach the tunnel endpoint.
IP checksum is calculated as usual.
The next fields are the tunnel entry as source address (the IP address of the HA) and the
tunnel exit point as destination address (the COA).

If no options follow the outer header, the inner header starts with the same fields
as just explained.
This header remains almost unchanged during encapsulation, thus showing the
original sender CN and the receiver MN of the packet.
The only change is TTL which is decremented by 1.
This means that the whole tunnel is considered a single hop from the original
packet's point of view.

Minimal encapsulation

Figure Minimal encapsulation

As seen with IP-in-IP encapsulation, several fields are redundant.

Minimal encapsulation is an optional encapsulation method for mobile IP.
Again, the tunnel entry point and endpoint are specified. In this case, the field for
the type of the following header contains the value 55 for the minimal encapsulation
protocol.
The inner header is different for minimal encapsulation. Still, the type of the
following protocol and the address of the MN are needed.
If the S bit is set, the original sender address of the CN is included.
No field for fragmentation offset is left in the inner header and, therefore, minimal
encapsulation does not work with already fragmented packets.

Generic routing encapsulation

While IP-in-IP encapsulation and minimal encapsulation work only for IP, the
following encapsulation scheme also supports other network layer protocols in addition
to IP.

Page 10
Unit – III

Generic routing encapsulation (GRE) allows the encapsulation of packets of

one protocol suite into the payload portion of a packet of another protocol suite
The packet of one protocol suite with the original packet header and data is taken
and a new GRE header is prepended.
Together this forms the new data part of the new packet. Finally, the header of the
second protocol suite is put in front.

Figure Generic routing encapsulation

Figure Protocol fields for generic routing encapsulation

The outer header is the standard IP header with HA as source address and COA
as destination address.
The protocol type used in this outer IP header is 47 for GRE.
The other fields of the outer packet, such as TTL and TOS, may be copied from
the original IP header.
The TTL must be decremented by 1 when the packet is decapsulated to prevent
indefinite forwarding.
The GRE header starts with several flags indicating if certain fields are present or
not.

Page 11
Unit – III

A minimal GRE header uses only 4 bytes; nevertheless, GRE is flexible enough to
include several mechanisms in its header.
The C bit indicates if the checksum field is present and contains valid
information.
If C is set, the checksum field contains a valid IP checksum of the GRE header
and the pay-load.
The R bit indicates if the offset and routing fields are present and contain valid
information.
The offset represents the offset in bytes for the first source routing entry.

GRE also offers a key field which may be used for authentication. If this field is
present, the K bit is set.
The sequence number bit S indicates if the sequence number field is present, if
the s bit is set, strict source routing is used.
The recursion control field (rec.) is an important field that additionally dis-
tinguishes GRE from IP-in-IP and minimal encapsulation. This field represents a counter
that shows the number of allowed recursive encapsulations.
As soon as a packet arrives at an encapsulator it checks whether this field equals
zero. If the field is not zero, additional encapsulation is allowed - the packet is
encapsulated and the field decremented by one.
Otherwise the packet will most likely be discarded.
This mechanism prevents indefinite recursive encapsulation which might happen
with the other schemes if tunnels are set up improperly (e.g., several tunnels forming a
loop). The default value of this field should be 0, thus allowing only one level of
encapsulation.
The following reserved fields must be zero and are ignored on reception.
The version field contains 0 for the GRE version.
The following 2 byte protocol field represents the protocol of the packet
following the GRE header.

Page 12
Unit – III

Optimizations
One way to optimize the route is to inform the CN of the current location of the
MN.
The CN can thus learn the location by caching it in a binding cache which is a
part of the local routing table for the CN. The appropriate entity to inform the CN of the
location is the HA.
The optimized mobile IP protocol needs four additional messages.

Binding request: Any node that wants to know the current location of an MN can send a
binding request to the HA. The HA can check if the MN has allowed dissemination of its
current location. If the HA is allowed to reveal the location it sends back a binding
update.

Binding update: This message informs about the current location of an MN. The
message contains the fixed IP address of the MN and the COA. The binding update can
request an acknowledgement.

Binding acknowledgement: If requested, a node returns this acknowledgement after

receiving a binding update message.

Binding warning: Finally, if a node decapsulates a packet for an MN, but it is not the
current FA for this MN, this node sends a binding warning to the HA of the MN. The
warning contains the IP address of the MN and the address of the node that has tried to
send the packet to this MN. The HA should now send a binding update to the node that
obviously has a wrong COA for the MN.

Figure Change of the foreign agent with the optimized mobile IP

1. The CN can request the current location from the HA.

2. If allowed by the MN, the HA returns the COA of the MN via an update message.
3. The CN acknowledges this update message and stores the mobility binding.
4. Now the CN can send its data directly to the current foreign agent FAold.
5. FAold forwards the packets to the MN. This scenario shows a COA located at an
FA. Encapsulation of data for tunnelling to the COA is now done by the CN, not
the HA.

Page 13
Unit – III

6. The MN might now change its location and register with a new foreign agent,
FAnew.
7. This registration is also forwarded to the HA to update its location database.
8. Furthermore, FAnew informs FAold about the new registration of MN. MN's
registration message contains the address of FAold for this purpose. Passing this
information is achieved via an update message, which is acknowledged by FAold.
9. In order to tell CN that it has a stale binding cache, FA old sends a warning message
to HA.
10. HA now sends an update to CN to inform it about the new location. CN
acknowledges this update.
11. Now CN can send its packets directly to FAne W, thus, again avoiding triangular
routing.

Page 14
Unit – III

Reverse tunnelling

Problems with IP Packet Delivery

Firewalls: Almost all companies and many other institutions secure their internal
networks connected to the Internet with the help of a firewall.
Besides many other functions, firewalls can be set up to filter out malicious
addresses from an administrator's point of view.
Quite often firewalls only allow packets with topologically correct addresses to
pass.
Furthermore, firewalls often filter packets coming from outside containing a
source address from computers of the internal network.

Multicast: Reverse tunnels are needed for the MN to participate in a multicast group.
While the nodes in the home network might participate in a multicast group, an MN in a
foreign network cannot transmit multicast packets in a way that they emanate from its
home network without a reverse tunnel.

TTL: Consider an MN sending packets with a certain TTL while still in its home
network. The TTL might be low enough so that no packet is transmitted outside a certain
region. If the MN now moves to a foreign network, this TTL might be too low for the
packets to reach the same nodes as before. Mobile IP is not transparent anymore if a user
has to adjust TTL while moving.
Therefore, a reverse tunnel is needed representing only one hop, no matter
how many hops are really needed from the foreign to the home network.

All these considerations led to RFC 2344 defining reverse tunnelling as extension to
mobile IP.
This RFC; is backwards-compatible to mobile IP and defines topologically correct
reverse tunnelling as necessary to handle the problems described above.
Reverse tunnelling additionally raises several security issues which have been not
solved up to now.

Page 15
Unit – III

DYNAMIC HOST CONFIGURATION PROTOCOL (DHCP)

The dynamic host configuration protocol is mainly used for the simplification of
installation and maintenance of networked computers.
If a new computer is connected to a network, DHCP can provide it with all
necessary information for full system integration into the network.
Especially the capability to provide an IP address makes DHCP very attractive for
mobile IP as a source of care-of addresses.

Basic DHCP Configuration

Figure Basic DHCP configuration

Page 16
 DHCP is based on a client/server model.
DHCP clients send a request to a server (DHCPDISCOVER) to which the server
responds.
A client sends requests using MAC broadcasts.
A DHCP relay might be needed to forward requests to a DHCP server.

Client Initialization

Figure Client initialization via DHCP

The figure shows one client and two servers.

1. The client broadcasts a DHCPDISCOVER into the subnet. There might be a
relay to forward this broadcast.
2. In the case shown, two servers receive this broadcast and determine the
configuration they can offer to the client.
3. Servers reply to the client's request with DHCPOFFER and offer a list of
configuration parameters.
4. Now the client can choose one of the offered configurations. The client in turn
replies-to the servers, accepting one of the configurations and rejecting the others
using DHCPREQUEST.
5. If a server receives a DHCPREQUEST with a rejection, it can free the reserved
configuration for other possible clients.
6. The server with the configuration accepted by the client now confirms the
configuration with DHCPACK.
This completes the initialization phase.
7. If a client leaves a subnet, it should release the configuration received by a server
using DHCPRELEASE.
 The configuration a client gets from a server is only leased for a certain amount of
time.
Therefore, the client has to reconfirm the configuration from time to time.
This time-out of configuration helps in case of crashed nodes or nodes moved away
without releasing the context.

Disadvantages

Security: There has been no authentication of DHCP messages specified. The mobile
node cannot trust a DHCP server, and the DHCP server cannot trust the mobile node.

Communication: There is no protocol for server-server configuration, i.e., one DHCP

server cannot communicate with another DHCP server and exchange currently used
configurations.

Address Space Fragmentation: Configurations on servers have to be set up by hand. An

administrator has to take care that every DHCP server has its own address space for
clients. This typically results in address space fragmentation.