Mobile IP Paresh Jain and Rakesh Kelkar

Technology Review#2003-02

Mobile IP:
Enabling Mobility for
the 3G Wireless
Internet

Paresh Jain
Rakesh Kelkar

April 2003
Mobile IP Paresh Jain and Rakesh Kelkar

© Copyright 2003 Tata Consultancy Services. All rights reserved

No part of this document may be reproduced or distributed in any form by any means
without prior written authorization of Tata Consultancy Services.
Mobile IP Paresh Jain and Rakesh Kelkar

Contents
1 INTRODUCTION ......................................................................................... 1
1.1 LISTOF ABBREVIATIONS .................................................................................... 1
2 WHAT IS MOBILE IP ................................................................................... 4
2.1 THE MOBILITY PROBLEM ................................................................................... 4
3 MOBILE IPV4 ENTITIES AND BEHAVIOUR ................................................. 6
3.1 ENTITIES....................................................................................................... 6
3.1.1 Behaviour ............................................................................................. 6
3.1.1.1 Agent Discovery .......................................................................................7
3.1.1.2 Registration .............................................................................................7
3.1.1.3 Routing and Packet Delivery ......................................................................8
3.1.1.4 Co-located Care-of Address .......................................................................9
3.1.1.5 Mobile IPv4 Route Optimisation .................................................................9
3.1.1.6 De-Registration ........................................................................................9
3.1.1.7 Security Considerations.............................................................................9
3.1.1.8 Message Authentication Codes................................................................. 10
3.1.1.9 Privacy .................................................................................................. 10
3.1.1.10 Replay Protection for Registration Requests .............................................. 10
3.1.1.11 Firewall Support ..................................................................................... 10
3.2 MOBILE IP FOR IPV6 ..................................................................................... 11
3.2.1 MIPv6 Overview.................................................................................. 11
3.2.2 Differences between MIP for IPv4 and IPv6 .......................................... 12
3.2.3 Security Considerations ....................................................................... 13
3.2.3.1 Mobile Node to Home Agent .................................................................... 13
3.2.3.2 Mobile Node to Correspondent Node ........................................................ 13
3.2.3.3 Tunnel Protection ................................................................................... 13
4 IMPLEMENTING MOBILE IP IN WIRELESS NETWORKS........................... 14
4.1 CDMA NETWORKS ........................................................................................ 14
4.1.1 Functional Relationships ...................................................................... 14
4.1.1.1 Mobile Station (MS) ................................................................................ 14
4.1.1.2 Radio Resources Control (RRC) and Packet Control Function (PCF) ............. 15
4.1.1.3 Packet Data Serving Node (PDSN) ........................................................... 15
4.2 UMTS/GPRS NETWORKS ............................................................................... 15
4.2.1 Functional Relationships ...................................................................... 16
4.2.1.1 Radio Network Subsystem (RNS) ............................................................. 16
4.2.1.2 SGSN .................................................................................................... 16
4.2.1.3 Gateway GPRS Support Node (GGSN) ...................................................... 16
4.2.1.4 Mobile IP Integration with UMTS/GPRS .................................................... 17
5 MOBILE IP RFCS ....................................................................................... 17
5.1 APPLICABILITY STATEMENT FOR IP MOBILITY SUPPORT .......................................... 17
5.2 ENCAPSULATION AND TUNNELLING ..................................................................... 17
5.2.1 IP Encapsulation within IP ................................................................... 17
5.2.2 Minimal Encapsulation within IP ........................................................... 17
5.2.3 Reverse Tunnelling for Mobile IP.......................................................... 18
5.3 MOBILE IP EXTENSIONS.................................................................................. 18
5.3.1 Mobile IPv4 Challenge/Response Extensions ......................................... 18
5.3.2 Mobile IP Vendor/Organization-Specific Extensions................................ 18
5.3.3 Mobile IP Network Access Identifier Extension for IPv4.......................... 18
5.4 MOBILE IP MANAGED OBJECT DEFINITIONS ......................................................... 19
5.5 MOBILE IP FIREWALL TRAVERSAL ...................................................................... 19
5.6 MOBILE IP AAA REQUIREMENTS ....................................................................... 19
5.7 MOBILE-IP CONFIGURATION OPTION FOR PPP IPCP ............................................. 19
Mobile IP Paresh Jain and Rakesh Kelkar

6 FUTURE DIRECTIONS ............................................................................... 20

6.1 MOBILE IP NAT/NAPT TRAVERSAL USING UDP TUNNELLING .................................. 20
6.2 REGISTRATION REVOCATION IN MOBILE IP .......................................................... 21
6.3 MOBILE IPV4 REGIONAL REGISTRATION ............................................................. 21
6.4 REQUIREMENTS OF A QOS SOLUION FOR MOBILE IP .............................................. 22
6.5 MOBILE IP SERVICE THROUGH MPLS ................................................................. 22
6.6 AAA NAI FOR MOBILE IPV4 EXTENSION ............................................................ 22
6.7 MOBILE IPV6 DRAFTS .................................................................................... 23
6.7.1 Fast Handovers for Mobile IPv6............................................................ 23
6.7.2 Localized Mobility Management Requirements for IPv6.......................... 23
6.7.3 Non-final Mobility Header for Mobile IPv6 ............................................. 23
6.7.4 Mobile IPv6 support in MPLS Network .................................................. 24
7 REFERENCES............................................................................................. 25

List of Figures
FIGURE 1 THE MOBILITY PROBLEM ................................................................................... 5
FIGURE 2 MOBILE IPV4 ARCHITECTURE ............................................................................. 7
FIGURE 3 MOBILE IP AGENT DISCOVERY SIGNALLING ............................................................ 7
FIGURE 4 MOBILE IP REGISTRATION SIGNALLING ................................................................. 8
FIGURE 5: MOBILE IP FOR IPV6..................................................................................... 11
FIGURE 6 CDMA NETWORK .......................................................................................... 14
FIGURE 7 UMTS NETWORK .......................................................................................... 16
Mobile IP Paresh Jain and Rakesh Kelkar Page 1 of 25

1 Introduction
Today, third generation mobile networks are fast becoming a reality. Operators are
developing and deploying UMTS and CDMA2000 services for their customers. These 3G
networks are enabling a new generation of applications based on mobile data access.

Convergence between current network technologies: the Internet and the mobile
telephony is thus taking place, but the Internet’s IP routing, was designed to work with
conventional static nodes not mobile nodes. Efforts are therefore being made in
Wireless and Internet forums to enhance IP routing to support mobility and many
proposals have been made in this direction.

Mobile IP is a key proposal from the Internet Engineering Task Force (IETF) that
specifies protocol enhancements to enable transparent routing of IP data packets to
mobile nodes in the Internet. This white paper thus consolidates and summarizes Mobile
IP concepts from the base RFC, as well as numerous related RFCs. It includes:

! An overview of Mobile IP for IPv4, including the mobility problem, mobility entities,
signalling and security

! An introduction to Mobile IP for IPv6

! Integration of Mobile IP with 3G wireless networks

! An overview of Mobile IP RFCs

! Future directions based on IETF drafts

A basic familiarity with the TCP/IP networking protocols suite, specifically IP routing, is
useful to appreciate the technologies and issues discussed in this white paper.

1.1 List of Abbreviations

Item Description

1X-CDMA Qualcomm’s 1X-CDMA protocol standard for wireless access

3G 3rd Generation (Refers to 3rd Generation Wireless Protocols

such as UMTS)

3GPP 3rd Generation Partnership Project

3GPP2 3rd Generation Partnership Project 2

AAA Authentication, Authorization, Accounting Protocol

CDMA Code Division Multiple Access, a wireless access protocol

developed by Qualcomm
Mobile IP Paresh Jain and Rakesh Kelkar Page 2 of 25

Item Description

CDMA2000 See 1X-CDMA

CH Correspondent Host

COA Care-of-Address

CR-LDP Constraint-based Routing using Label Distribution Protocol

DHCP Dynamic Host Configuration Protocol

DHCPv6 Dynamic Host Configuration Protocol for IPv6

DNS Domain Name Service

EDGE Enhanced Data GSM Environment

FA Foreign Agent

GPRS General Packet Radio Services, a wireless access protocol based

on GSM

GSM Global System for Mobile communication

HA Home Agent

HLR Home Location Register

ICMP Internet Control Message Protocol (defined in RFC 792)

IETF Internet Engineering Task Force

IMT-2000 International Mobile Telecommunications – 2000

IP Internet Protocol (defined in RFC 791)

IPsec IP Security Protocol

LDP Label Distribution Protocol

LER Label Edge Router

LSP Label-Switched Paths

MIPv4 Mobile IP for IPv4 (Internet Protocol version 4)

MIPv6 Mobile IP for IPv6 (Internet Protocol version 6)

MN Mobile Node
Mobile IP Paresh Jain and Rakesh Kelkar Page 3 of 25

Item Description

MPLS Multi-protocol Label Switching

NAT Network Address Translation

PDSN Packet Data Serving Node (See [5])

PLMN Public Land Mobile Network

PPP Point to Point Protocol (See [8])

QoS Quality of Service

ROAMOPS Roaming Operations, an IETF Working Group (see

http://www.ietf.org/html.charters/roamops-charter.html)

RRP Mobile IP Registration Reply Message

RRQ Mobile IP Registration Request Message

RSVP Resource ReSerVation Protocol

RSVP-TE Extensions to RSVP for LSP Tunnels

TCP Transmission Control Protocol (defined in RFC 793)

UMTS Universal Mobile Telephony System, a 3G wireless access

protocol developed by 3GPP

VLR Visitor Location Register

Mobile IP Paresh Jain and Rakesh Kelkar Page 4 of 25

2 What is Mobile IP

2.1 The Mobility Problem

These days more and more people enjoy the advantages of the portability and flexibility
of carrying their workstations in the form of laptops, notebooks, and PDA handsets. To
meet the needs of this new set of users, existing computing environments based on
fixed networks are being extended into the mobile domain. 3G and wireless networks
are seen as a major revenue stream by providing an additional level of flexibility and
service to the user.

For data access services and multimedia communication, it is seen as desirable to adapt
traditional applications and services people are accustomed to use in the fixed network,
and extend them to make them available to the mobile user in a seamless manner.

The most dominant services in mobility are the Internet/Intranet services, which run on
top of the IP protocol. Internet host mobility poses a problem at the network layer (IP)
when a mobile node moves from one sub-net to another. Routing tables have to be
updated to route packets to the destination sub-net instead of the original sub-net.

This procedure is highly inefficient and time consuming, in particular, if a mobile host
needs to retain its network address (IP address) while changing sub-nets. But if a
mobile host changes its network address, all established Transport Layer connections
(TCP) are broken.
Mobile IP Paresh Jain and Rakesh Kelkar Page 5 of 25

Figure 1 The Mobility Problem

For example, imagine a commuter downloading music while travelling by train (See
Figure 1). This user is using a laptop attached to a mobile handset. The mobile handset
could be connected to the Internet using data services provided by GSM or CDMA
networks.

When the user registers for data services, i.e. the user initiates a data call, he/she will
be assigned a unique IP address. Once connected, the user starts an FTP session to
download music from the Internet. This FTP session is based on a Transport Layer
connection that is dependent on the connection invariant1.

But as the train moves, the mobile station moves to another cell; the point of
attachment for data services and therefore the sub-net, may change (for instance, if the
user moves across service providers—roaming). If the mobile station is now assigned a
new IP address, all the transport layer connections will break down. The FTP session will
therefore be aborted.

This is the problem that Mobile IP seeks to solve. Specifically, Mobile IP defines a set of
entities that enable routing of packets to the Mobile Node (in this case, the mobile

1
The Connection Invariant: <source IP address, port, destination IP address, port > Must be unique and
constant for each connection lifetime.
Mobile IP Paresh Jain and Rakesh Kelkar Page 6 of 25

handset plus laptop computer) without requiring major changes to Internet routing
tables.

3 Mobile IPv4 Entities and Behaviour

3.1 Entities
Mobile IPv4 consists of three components: the mobile node, a home agent and a foreign
agent. A node that moves from a sub-net to another sub-net is called a Mobile Node
(MN) and its IP address is called a Home Address. A Correspondent Node (CN) is the
host with which the Mobile Node is trying to communicate, on the Internet.

The sub-net, to which the Home Address belongs, is called the Home Network and the
routing entity on this Home Network that does the job of forwarding packets to the
Mobile Nodes is called the Home Agent.

When the mobile node moves to another sub-net, this new sub-net is called the Foreign
Network. The routing entity receiving packets on behalf of the mobile node on the
Foreign Network is called the Foreign Agent.

The foreign agent (or the mobile node itself under certain conditions) operates as a
router on the foreign network that the mobile node is visiting. A router is a device
(hardware or software), that determines the next network point, to which a network
data packet should be forwarded, toward its destination. A router is connected to at
least two networks and decides which way to send each information packet, based on
its current understanding of the state of the networks to which it is connected.

Because of the operation of these Mobile IP entities, no changes are needed in any
other part of the Internet, including routers or other systems such as DNS.

3.1.1 Behaviour
There are three stages in the operation of the Mobile IP:

Agent Discovery: This refers to the process by which a Mobile Node discovers a
Mobility Agent (Home Agent or Foreign Agent) on a Foreign Network.

Registration: This refers to the process by which a Mobile Node registers itself on a
Foreign Network with the Home Agent for Mobile IP Routing and Packet Delivery
Services.

Routing and Packet Delivery: This refers to the process by which packets are routed
from a Mobile Node to a Correspondent Host and back.
Mobile IP Paresh Jain and Rakesh Kelkar Page 7 of 25

Figure 2 Mobile IPv4 Architecture

3.1.1.1 Agent Discovery

When a mobile node attaches to a network, it first determines whether it is on its home
network or on a foreign network. It does so by listening for a local broadcast message
from a home agent or foreign agent. This message is called an Agent Advertisement.

Alternatively, it can solicit an agent advertisement by broadcasting an Agent Solicitation

message. These messages are based on extensions to ICMP Router Discovery Messages
[6].

Figure 3 Mobile IP Agent Discovery Signalling

3.1.1.2 Registration
When a Mobile Node is visiting a Foreign Network – detected by the Mobile Node
through the Agent Discovery procedure, the Mobile Node must “Register” with the
Foreign Agent.

Registration informs the Foreign Agent of the presence of a Mobile Node requiring
routing services on its sub-net. Registration also informs the Home Agent of the current
location (sub-net) and care-of address of the Mobile Node.

The care-of address refers to an address local to the Foreign Network that the Mobile
Node is currently visiting. This address is accessible through normal IP routing. It could
be the address of the Foreign Agent or an address dynamically assigned to the Mobile
Node.
Mobile IP Paresh Jain and Rakesh Kelkar Page 8 of 25

To register, the Mobile Node sends a Registration Request message (RRQ) to the
Foreign Agent. The RRQ is a UDP message sent to port 434. The Foreign Agent
processes the message and forwards it to the Home Agent (as specified in the RRQ or
dynamically assigned).

On receiving a valid RRQ, the Home Agent creates a mobility binding (or updates an
existing binding) that pairs the Mobile Node Home Address with the current Care-of
Address. The Home Agent sends a Registration Reply (RRP) with a code indicating
registration success to the Foreign Agent. The Foreign Agent relays the RRP to the
Mobile Node.

Figure 4 Mobile IP Registration Signalling

3.1.1.3 Routing and Packet Delivery

On successful registration, the Home Agent then sets up an IP tunnel between itself and
the Care-of Address indicated in the RRP. This is usually the address of the Foreign
Agent. This tunnel is used to encapsulate and forward IP packets, destined for the
Mobile Node, to the Foreign Network over the Internet. The Foreign Agent decapsulates
the packets and routes them to the Mobile Node using a static route. In order to
intercept packets destined for the Mobile Node, the Home Agent implements Proxy ARP
(Address Resolution Protocol) procedures.

Packets from the mobile node to the target host (Correspondent Node) can be routed
directly bypassing the home agent as the destination IP address – that of the
Correspondent Node is reachable using normal IP routing. This results in a triangular
routing of traffic between the Mobile Node, Correspondent Node and Home Agent.
Outgoing packets from the Mobile Node to the Correspondent Node are routed directly,
while incoming packets from the Correspondent Node to the Mobile Node are routed via
the Home Agent. This is not necessarily efficient, but is effective.

In addition, when a mobile node changes its location, it can register with a new foreign
agent, though traffic directed by the home agent to the "old" foreign agent will be lost
until the new mobile node has registered its location.

In some cases such as routers with ingress filtering, packets whose source address does
not match the source sub-net (such as a Mobile Node visiting a Foreign Network) are
blocked. In this case, the Mobile Node is forced to request reverse tunnelling. Reverse
tunnelling refers to the tunnelling by the Foreign Agent to the Home Agent of all
outgoing packets of the Mobile Node. Outgoing packets are therefore tunnelled to the
Home Network and then routed to the Correspondent Node.
Mobile IP Paresh Jain and Rakesh Kelkar Page 9 of 25

3.1.1.4 Co-located Care-of Address

A mobile node can obtain a care-of address in two ways:

! From a foreign Agent via the Agent Discovery and Registration Features described
above.

! As a co-located address, such as one obtained via DHCP.

A mobile node may obtain a co-located address when it is unable to find a Foreign
Agent on the foreign network. The co-located address is obtained using standard
mechanisms like DHCP. Once a co-located address has been obtained, the mobile node
follows the Mobile IP registration procedure to register the address with the Home
Agent. On successful registration, it creates the required routing and tunnelling entries.

A mobile node with a co-located care-of address thus acts as a foreign agent for the
purpose of registration with the home network, in addition to mobile node functionality.

3.1.1.5 Mobile IPv4 Route Optimisation

Triangle routing under Mobile IP often causes datagrams2 to the Mobile Node to be
routed along paths that are significantly longer than optimal (via the Home Agent). This
indirect routing delays the delivery of the datagrams to mobile nodes, and places an
unnecessary burden on the networks and routers along their paths through the
Internet.

Mobile IPv4 Route Optimisation (See [15]) defines extensions to the operation of the
base Mobile IP protocol to allow the correspondent node to maintain a binding cache to
one or more Mobile Nodes. Route Optimisation also allows for a means for the mobile
node's previous foreign agent to be reliably notified of the mobile node's new mobility
binding, allowing datagrams in flight to the mobile node's previous foreign agent to be
forwarded to its new care-of address. This notification also allows any resources
consumed by the mobile node at the previous foreign agent (such as radio channel
reservations) to be released immediately.

3.1.1.6 De-Registration
If the mobile node is on its home sub-net, as specified by its Home Address, no special
routing support is required. The mobile node therefore informs the home agent of its
presence on the home sub-net through de-registration. From then on, routing and
datagram3 delivery work as they would without Mobile IP.

3.1.1.7 Security Considerations

The mobile or wireless computing or communication environment is insecure in
comparison with a wire-line environment. Mostly mobile computers will be connected to
the network via wireless links. Such links are actively and passively vulnerable to
eavesdropping, replay attacks, and other attacks. The following sections list the security
provisions in Mobile IP.

2
According to RFC 1594, a datagram is, "a self-contained, independent entity of data carrying sufficient
information to be routed from the source to the destination computer without reliance on earlier exchanges
between this source and destination computer and the transporting network."
Mobile IP Paresh Jain and Rakesh Kelkar Page 10 of 25

3.1.1.8 Message Authentication Codes

According to [14], home agents and mobile nodes should support authentication. The
default algorithm for authentication is MD5 (See [7]), with a key size of 128 bits. The
default mode of operation is to both precede and follow the data to be hashed, by the
128-bit key; that is, MD5 is to be used in prefix-plus-suffix mode. The foreign agent also
supports authentication using keyed MD5 and key sizes of 128 bits or greater, with
manual key distribution.

3.1.1.9 Privacy
Those users who do not want others to peep into the data can use encryption
mechanisms. If absolute location privacy is required, the mobile node can create a
tunnel to its home agent. All datagrams destined for correspondent nodes will appear to
emanate from the home network, and it will make it difficult for hackers to pinpoint the
location of the mobile node.

Implementing IPsec for Mobile IP is to protect the redirected packets sent from or to a
mobile node against active/passive attack. In addition, this mechanism also helps
packets sent by mobile nodes to traverse the firewall of the visiting or home network.
The standardization of this work is still in progress in IETF and the current draft (see
[12]) supports IP-in-IP encapsulation, only between the mobile node and its home
agent.

3.1.1.10 Replay Protection for Registration Requests

To protect mobile IP entities from Replay attackers, two methods have been described
in the Mobile IP RFC. Replay attackers are those who record and re-play datagrams in
order to get entry into the system.

! Timestamps: A Node generating a message inserts the current time of day, and the
node receiving the message checks that this timestamp is sufficiently close to its
own time of day.

! Nonces: Node A includes a new random number in every message to Node B, and
checks that Node B returns that same number in its next message to Node A. Both
messages use an authentication code to protect against alteration by an attacker.

The timestamps option is mandatory while that for nonces is optional. Whatever method
is used, the low-order 32 bits of the Identification are copied unchanged from the
Registration Request to the Reply. The foreign agent uses those bits to match
Registration Requests with corresponding replies. The mobile node verifies that the low-
order 32 bits of any Registration Reply are identical to the bits it sent in the Registration
request.

3.1.1.11 Firewall Support

Firewalls exist between private networks and a public network. They are used to filter
incoming and outgoing packets. For the delivery of packets attempting to travel into a
private network, the destination address of these packets targets the firewall of the
private network. Once the packets arrive at the firewall, they are forwarded if the
firewall has a security association with the source.
Mobile IP Paresh Jain and Rakesh Kelkar Page 11 of 25

IETF RFC 2356 describes what support is required at the firewall, the Mobile IP Home
Agent and the Mobile IP Mobile Node, to enable the Mobile Node to access a private
network from the Internet.

The most preferred mechanism as per the RFC is the “Simple Key-Management for
Internet Protocols (SKIP)” mechanism. Using SKIP for this purpose has two main
advantages:

! Each SKIP packet contains an authentication header. As a result, decisions relating

to packets arriving at a firewall can be taken immediately without requiring any
costly roundtrips for negotiation with the mobile node.

! SKIP meets the demand of mobility in that the security association can be built
based on a key in the SKIP header rather than on source and destination addresses.

3.2 Mobile IP for IPv6

Figure 5: Mobile IP for IPv6

3.2.1 MIPv6 Overview

The main difference between the solutions proposed for IPv4 and for IPv6 is that in
IPv4, traffic forwarding to the mobile node is almost always managed through a foreign
agent, whereas in IPv6, the foreign agent no longer exists and it is assumed that the
Mobile IP Paresh Jain and Rakesh Kelkar Page 12 of 25

mobile node is always able to acquire a co-located care-of address belonging to the
visited sub-net4.

The foreign agent of MIPv4 was basically conceived to reduce the demand for IP
addresses by sharing the same care-of address amongst several mobile nodes. A foreign
agent made it possible to avoid aggravating the problem of limited IPv4 addressing
space. This is no longer an issue with IPv6, which has a virtually unlimited addressing
space and efficient auto-configuration mechanisms. The mobile node can use these
mechanisms (such as DHCPv6) to acquire a valid address in the visited sub-net.

Movement detection that took the form of Agent Advertisements in MIPv4 is replaced by
IPv6 mechanisms like neighbour discovery (see [4]).

3.2.2 Differences between MIP for IPv4 and IPv6

! Mobile IPv4 allows the use of Foreign Agents (FAs) to forward traffic, thus requiring
one care-of address for multiple mobile nodes. It also supports the use of co-located
care-of addresses (COA). In contrast, MIPv6 supports co-located COAs only.

! Route optimisation is an add-on to MIPv4, whereas it is an integral part of the

MIPv6 specification. This is because all IPv6 nodes have to support the IPv6
Destination option “Home Address”. This option allows an MN to set the IP source
address to its Care-of Address, while requiring the Correspondent Node to substitute
it with the Home Address for higher layer processing.

! MIPv4 route optimisation requires traffic to be tunnelled between the correspondent

host (CH) and the mobile node. In MIPv6, packets can be forwarded without
tunnelling, as the source address is always the care-of address.

! In MIPv4, the Home Agent (HA) must be involved in the set-up of optimised routes.
In MIPv6, the mobile node can initiate an optimised route to a CH directly (without
involving the HA), and therefore more quickly and efficiently.

! In MIPv4, a COA is obtained from an FA or via DHCPv4. In MIPv6, a COA can be

obtained via IPv6 stateless or stateful address auto-configuration mechanisms.

! In MIPv4, separate Mobile IP-specific messages are required to communicate with

the FA, and HA, and if employing route optimisation, with CHs. In MIPv6, Mobile IP-
specific information can be piggybacked onto data packets.

! In MIPv4, reverse tunnelling is required to avoid ingress filtering problems (where

firewalls drop the mobile's outgoing packets as they appear to originate from an
unknown sub-net), since packets are sent with the home address as the source. In
MIPv6, packets may be sent with the COA as the source address, hence ingress
filtering problems are avoided (see 3.1.1.3).

! MIPv4 provides its own security mechanisms, whereas MIPv6 employs the IPsec
protocol suite.

4
Stateless Address Auto-configuration: New IP Address =Routing Prefix + MAC Address
Mobile IP Paresh Jain and Rakesh Kelkar Page 13 of 25

3.2.3 Security Considerations

Potential security threats in Mobile IPv6 include denial of service, potential for man-in-
the-middle, hijacking, and impersonation attacks. The MIPv6 specification provides a
number of security features. The main features are:

! Protection of Binding Updates to home agents

! Protection of Binding Updates to correspondent nodes

! Protection against reflection attacks through the Home Address destination option

! Protection of tunnels between the mobile node and the home agent

! Preventing Routing Header vulnerabilities

! Preventing Denial-of-Service attacks to the Mobile IPv6 security mechanisms

themselves

3.2.3.1 Mobile Node to Home Agent

Mobile nodes and home agents are expected to be subject to the network
administration of the home domain. Therefore, they have a strong security association
to reliably authenticate exchanged messages. With such a security arrangement, IPsec
Encapsulating Security Payload (ESP) can be used to implement the security features.

3.2.3.2 Mobile Node to Correspondent Node

An "infrastructureless" approach is necessary to authenticate mobile nodes and
correspondent nodes. This is because Mobile IPv6 use is expected to be global between
nodes belonging to different administrative domains.

Requiring that a Binding Update is cryptographically bound to exchanged cookies limits

the vulnerabilities to attackers who are on the path between the home agent and the
correspondent node.

3.2.3.3 Tunnel Protection

Ensuring proper use of source addresses and optional cryptographic protection can
protect tunnels between the mobile node and the home agent. For tunnelled traffic to
and from the mobile node, encapsulating the traffic inside IPsec ESP offers an optional
mechanism to protect the confidentiality and integrity of the traffic against on-path
attackers.
Mobile IP Paresh Jain and Rakesh Kelkar Page 14 of 25

4 Implementing Mobile IP in Wireless Networks

4.1 CDMA Networks

The Wireless IP Network Standard (See [5]) defines requirements for support of
wireless packet data networking capability on a 3G wireless system based on
CDMA2000. As a general philosophy behind the design, IETF protocols have been
employed whenever possible to minimize the number of new protocols required.

The system design objectives of Wireless IP include:

! Supporting a wide range of addressing configurations (dynamic and static home

address configurations, multiple simultaneous IP addresses and dynamic assignment
of the Home Agent)

! Providing seamless roaming (Allow IP mobility for visitors whose home network may
be an IMT-2000 network, ISP, or private network)

! Providing robust authentication and authorization services (AAA support services)

! Providing QoS support for differentiated services

! Providing accounting services

4.1.1 Functional Relationships

Figure 6 CDMA Network

4.1.1.1 Mobile Station (MS)

The Mobile Station is the Mobile IP “Mobile Node”; it connects via a data link protocol
(PPP) to the PDSN. The MS can hand off between PDSNs that do not involve the home
IP network using Mobile IP and accept an HA dynamically assigned by the AAA in the
Mobile IP Paresh Jain and Rakesh Kelkar Page 15 of 25

service provider network or home IP network. An MS may use a static home address, or
a dynamically assigned home address.

In addition to this, the MS can buffer packets from the mobile applications when radio
resources are not in place, or are insufficient to support the flow to the network.

4.1.1.2 Radio Resources Control (RRC) and Packet Control Function (PCF)
The RRC (See [5]) is the entity to which the MS connects on the air-interface. The RRC
is responsible for establishing, maintaining, and terminating radio resources for the
exchange of packets between the mobile station and the Packet Control Function (PCF,
see [5]).

The RRC and the PCF are located at the “Radio Network” as seen in Figure 6 CDMA
Network.

The PCF entity relays packets to and from the PDSN. It connects at layer 2 to the PDSN
and communicates with the RRC to request and manage radio resources in order to
relay packets to and from the mobile station. The PCF also collects and sends air-link
related accounting information to the PDSN.

The PCF can buffer packets arriving from the PDSN, when radio resources are not in
place or are insufficient to support the flow from the PDSN.

4.1.1.3 Packet Data Serving Node (PDSN)

The PDSN is the entity that supports Foreign Agent functionality. It establishes,
maintains, and terminates a PPP session to the mobile station. The PDSN maps the
mobile station IP and HA addresses with a unique link layer identifier used to
communicate with the PCF.

The PDSN sends Agent Advertisement(s) (see [14]) if the PCF indicates that the mobile
station has undergone a handoff. The PDSN may also optionally interact with a previous
PDSN to support handoffs between PDSNs that do not involve the home IP network.

The PDSN can route packets to IP networks or directly to the HA in the case of reverse
tunnelling. It also monitors the source addresses of packets received from mobile
stations. When packets are received, which have source addresses not assigned or
registered to the mobile station, the PDSN discards the packets and restarts PPP to the
mobile station.

4.2 UMTS/GPRS Networks

According to [1], the requirements for the UMTS packet domain are to:

! Efficiently support IP transport and access to the Internet

! Enable support of Virtual Private Networks

! Enable support of Remote Network Access

Mobile IP Paresh Jain and Rakesh Kelkar Page 16 of 25

! Enable roaming procedures based on IETF ROAMOPS working group and AAA
working group outcomes. This implies the support of NAI (Network Access
Identifier)-based Roaming procedures and IETF standard AAA procedures. This
would allow sharing of standard Internet AAA infrastructure.

! Provide end-to-end QoS or service differentiation according to IETF standards for IP

packet transport

! Support of Mobile IP with Challenge/Response based authentication (See [13]) and

NAI extension, in order to inter-operate with operators, corporations and ISPs
offering Mobile IP on the core network side

4.2.1 Functional Relationships

Figure 7 UMTS Network

4.2.1.1 Radio Network Subsystem (RNS)

The GPRS/ UMTS network consists of two parts: the core network and the radio access
network. The radio access network connects the users to the core network. It contains
the base stations (Node B), the radio network controller (RNC) and the network
elements MSC and SGSN, which connect the UTRAN to the core network. The Node Bs
in one RNC region are called radio network subsystem (RNS); these RNSs are connected
to this RNC, which is connected with the respective U-MSCs (MSC/SGSN).

4.2.1.2 SGSN
The serving GPRS support node (SGSN) forwards packets to and from mobile devices
within its service area. The SGSN is responsible for Mobility Management and
Authentication.

4.2.1.3 Gateway GPRS Support Node (GGSN)

The GGSN is responsible for address allocation to the MS and acts as a gateway to
external networks.

The GGSN acts as an interface between the GPRS backbone network and inbound
external packet data networks such as the Internet and corporate networks.
Mobile IP Paresh Jain and Rakesh Kelkar Page 17 of 25

The GGSN converts the GPRS packets coming from the SGSN into the appropriate
packet data protocol (PDP) format. If the PDP type is PPP, the GGSN acts as the PPP
end point, if the type is IP, then it acts as an IP end-point. The GGSN then sends the
packets out on the corresponding packet data network.

4.2.1.4 Mobile IP Integration with UMTS/GPRS

Mobile IP will be supported in UMTS/GPRS in the following manner.

! Stage One: Foreign Agent functionality will be added to only one GGSN in the PLMN.
This implies that there will be no change in the network architecture and no change
will be required in the Mobile Station either. This stage allows for mobility across
PLMNs.

! Stage Two: Enhance the GGSN with Foreign Agent (FA) functionality into a
GGSN/FA. This will allow a GGSN to be changed if a more suitable GGSN is
available. This stage will ensure a more efficient use of PLMN backbone resources
by creating mobility at the GGSN/SGSN pair level.

! Stage Three: Merge the SGSN and GGSN/FA into an IGSN (Internet GPRS Support
Node). This stage will provide true Mobile IP macro mobility management.

5 Mobile IP RFCs
This section provides an overview of the IETF RFCs for Mobile IP, apart from the base
RFC 3220 (updates RFC 2002).

5.1 Applicability Statement for IP Mobility Support

RFC 2005 discusses the applicability of Mobile IP to provide host mobility in the
Internet. In particular, this RFC describes the key features of Mobile IP and shows how
the requirements for advancement to the Proposed Standard RFC have been satisfied.

5.2 Encapsulation and Tunnelling

5.2.1 IP Encapsulation within IP

RFC 2003 specifies a method by which an IP datagram may be encapsulated (carried as
payload) within another IP datagram. Encapsulation is suggested as a means to alter
the normal IP routing for datagrams. This causes the datagrams to be delivered to an
intermediate destination that would otherwise not be selected by the IP Destination
Address field in the original IP header. Encapsulation may serve a variety of purposes,
such as delivery of a datagram to a mobile node, using Mobile IP.

5.2.2 Minimal Encapsulation within IP

RFC 2004 specifies a method by which an IP datagram may be encapsulated (carried as
payload) within an IP datagram, with lower overhead than "conventional" IP
encapsulation that adds a second IP header to each encapsulated datagram.
Encapsulation is suggested as a means to alter the normal IP routing for datagrams, by
delivering them to an intermediate destination that would otherwise not be selected by
the (network part of the) IP Destination Address field in the original IP header.
Mobile IP Paresh Jain and Rakesh Kelkar Page 18 of 25

Encapsulation may be serving a variety of purposes, such as delivery of a datagram to a

mobile node using Mobile IP.

5.2.3 Reverse Tunnelling for Mobile IP

Mobile Internet Protocol (IP) uses tunnelling from the home agent to the mobile node's
care-of address, but rarely in the reverse direction. Usually, a mobile node sends its
packets through a router on the foreign network, and assumes that routing is
independent of source address. When this assumption is not true, it is convenient to
establish a topologically correct reverse tunnel from the care-of address to the home
agent.

RFC 3024 proposes backward-compatible extensions to the Mobile IP to support

topologically correct reverse tunnels. It does not attempt to solve the problems posed
by firewalls located between the home agent and the mobile node's care-of address.

5.3 Mobile IP Extensions

5.3.1 Mobile IPv4 Challenge/Response Extensions

Mobile IP, as originally specified, defines an authentication extension (the Mobile-
Foreign Authentication extension), by which a mobile node can authenticate itself to a
foreign agent.

Unfortunately, this extension does not provide ironclad replay protection for the foreign
agent and does not allow for the use of existing techniques (such as CHAP) for
authenticating portable computer devices.

RFC 3012 defines extensions for the Mobile IP Agent Advertisements and the
Registration Requests that allow a foreign agent to use a challenge/response
mechanism to authenticate the mobile node.

5.3.2 Mobile IP Vendor/Organization-Specific Extensions

RFC 3115 defines two new extensions to Mobile IP. These extensions will facilitate
equipment vendors and organizations to make specific use of these extensions as they
see fit for research or deployment purposes.

5.3.3 Mobile IP Network Access Identifier Extension for IPv4

AAA servers are in use within the Internet today to provide authentication and
authorization services for dial-up computers. Such services are likely to be equally
valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to
foreign domains with AAA servers.

AAA servers today identify clients by using the Network Access Identifier (NAI). RFC
2794 defines a way for the mobile node to identify itself, by including the NAI along
with the Mobile IP Registration Request. The RFC (2794) also updates RFC 2290, which
specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's
Home Address field of this option to be zero.
Mobile IP Paresh Jain and Rakesh Kelkar Page 19 of 25

5.4 Mobile IP Managed Object Definitions

RFC 2006 defines the Management Information Base (MIB) for use with network
management protocols in TCP/IP-based Internets using SMIv2. In particular, it describes
managed objects used for managing the Mobile Node, Foreign Agent and Home Agent
of the Mobile IP Protocol.

5.5 Mobile IP Firewall Traversal

The Mobile IP specification establishes the mechanisms that enable a mobile host to
maintain and use the same IP address as it changes its point of attachment to the
network. Mobility implies higher security risks than static operation, because the traffic
may at times take unforeseen network paths with unknown or unpredictable security
characteristics.

The Mobile IP specification makes no provisions for securing data traffic. The
mechanisms described in RFC 2356 allow a mobile node out on a public sector of the
Internet to negotiate access past a SKIP firewall, and construct a secure channel into its
home network.

In addition to securing traffic, this RFC defines mechanisms to allow a mobile node to
roam into regions that:

! Impose ingress filtering, and

! Use a different address space.

5.6 Mobile IP AAA Requirements

RFC 2977 defines the requirements for Authentication, Authorization, and Accounting.
This RFC contains the requirements, which are to be supported by an AAA service to aid
in providing Mobile IP services.

5.7 Mobile-IP Configuration Option for PPP IPCP

The Mobile IP defines media-independent procedures by which a Mobile Node can
maintain existing transport and application-layer connections, despite changing its point-
of-attachment to the Internet and without changing its IP address.

PPP [RFC 1661] provides a standard method for transporting multi-protocol packets
over point-to-point links. As currently specified, Mobile IP Foreign Agents, which support
Mobile Node connections via PPP, can do so only by first assigning unique addresses to
those Mobile Nodes, defeating one of the primary advantages of Foreign Agents.

RFC 2290 corrects this problem by defining the Mobile-IPv4 Configuration Option to the
Internet Protocol Control Protocol (IPCP) [RFC 1332]. Using this option, two peers can
communicate their support for Mobile IP during the IPCP phase of PPP. Familiarity with
Mobile IP [RFC 2002], IPCP [RFC 1332], and PPP [RFC 1661] is assumed.

This RFC (2990) has been updated by RFC 2794, which presents the preferred method
for Wireless IP (see [5]).
Mobile IP Paresh Jain and Rakesh Kelkar Page 20 of 25

6 Future Directions
This section lists the directions that Mobile IP is taking by summarising the Internet
drafts currently valid with IETF in the Mobile IP area.

6.1 Mobile IP NAT/NAPT Traversal using UDP Tunnelling

Mobile IP's datagram tunnelling is incompatible with Network Address Translation
(NAT). The draft by H. Levkowetz (ipUnplugged), S. Vaarala (Netseal) released in April,
2002, presents extensions to the Mobile IP protocol and a tunnelling method which
permits mobile nodes using Mobile IP to operate in private address networks, which are
separated from the public internet by NAT devices.

The NAT traversal is based on using the Mobile IP Home Agent UDP port for
encapsulated data traffic. Mobile IP relies on sending traffic from the home network to
the mobile node or foreign agent through IP-in-IP tunnelling. IP nodes, which
communicate from behind a NAT, are reachable only through the NAT's public
address(es). IP-in-IP tunnelling does not generally contain enough information to permit
unique translation from the common public address(es) to the particular care-of address
of a mobile node or foreign agent, which resides behind the NAT. For this reason, IP-in-
IP tunnels cannot, in general, pass through a NAT, and Mobile IP will not work across a
NAT.

Mobile IP's Registration Request and Reply will, on the other hand, be able to pass
through NATs and NAPTs on the mobile node or foreign agent side, as they are UDP
datagrams originated from the inside of the NAT or NAPT. When passing out, they make
the NAT set up an address/port mapping, through which the Registration Request will
be able to pass in to the correct recipient.

In MIP UDP tunnelling, the mobile node may use an extension (described in the draft) in
its Registration Request to indicate that it is able to use Mobile IP UDP tunnelling,
instead of standard Mobile IP tunnelling, if the home agent sees that the Registration
Request seems to have passed through a NAT.

After assent from the home agent, MIP UDP tunnelling will be available for use for both
forward and reverse tunnelling. UDP tunnelled packets sent by the mobile node use the
same ports as the registration request message.
Mobile IP Paresh Jain and Rakesh Kelkar Page 21 of 25

6.2 Registration Revocation in Mobile IP

During the original design of Mobile IP, the need for an administrative domain to be
able to actively revoke a current Mobile IP registration was recognized. Due to the lack
of a specific scenario requiring such a mechanism, it was decided that instead of an
active revocation mechanism explicitly for the purpose of registration revocation, a
passive mechanism, namely short registration lifetimes, and the denial of a subsequent
registration from a mobile node, would likely be sufficient for this purpose.

Investigations into requirements for an AAA protocol within the AAA working group have
forced reconsideration of a more pro-active Mobile IP registration revocation feature,
whereby both domains providing Mobile IP services are aware that the service is being
suspended.

In the ideal model, revocations must be possible from either home or foreign domains,
and any registration revocation mechanism being defined must also provide a signalling
mechanism between the two that the current registration has been released. Mobile IP
services are no longer being provided on one side of the registration, so they need not
be provided on the other. In some cases, the current registration may be terminated to
simply force the mobile node to renegotiate its registration, but in other cases, where
no renegotiation will be considered by the terminating side, this should be
communicated.

Moreover, there should also be a mechanism in place, whereby the mobile node whose
registration has been terminated, can also be informed that such a revocation has
occurred. This is done if only to make it clear that the mobile node is no longer being
provided Mobile IP services, though the reasons for such a revocation need not
necessarily be relayed.

The draft by S. Glass (Sun Microsystems), and M. Chandra (Cisco Systems) released in
March 2002, defines such a general use registration revocation mechanism meeting
these requirements.

6.3 Mobile IPv4 Regional Registration

If the distance between the visited network and the home network of the mobile node is
large, the signalling delay for these registrations may be long. The draft by Eva
Gustafsson (Ericsson), Annika Jonsson (Ericsson), and Charles E. Perkins (Nokia
Research Center) released in March 2002, proposes a new kind of "regional"
registration, i.e., registration local to the visited domain. Regional registrations reduce
the number of signalling messages to the home network, and reduce the signalling
delay when a mobile node moves from one foreign agent to another, within the same
visited domain.

When a mobile node first arrives at a visited domain, it performs a home registration –
that is, a registration with its home agent. At this registration, we assume that the home
network generates a registration key for the mobile node. This registration key is
distributed to the mobile node and to the visited domain, and can be used for
authentication of regional registrations.
Mobile IP Paresh Jain and Rakesh Kelkar Page 22 of 25

During a home registration, the home agent registers the care-of address of the mobile
node. When the visited domain supports regional tunnel management, the care-of
address that is registered by the home agent is the publicly routable address of a
Gateway Foreign Agent (GFA). This care-of address will not change when the mobile
node changes the foreign agent under the same GFA. When changing the GFA, a mobile
node MUST perform a home registration; when changing the foreign agent under the
same GFA, the mobile node MAY instead perform a regional registration within the
visited domain.

6.4 Requirements of a QoS Soluion for Mobile IP

Mobile IP needs to provide proper Quality of Service (QoS) forwarding treatment to a
mobile node's packet stream at the intermediate nodes in the network. This will ensure
support for QoS-sensitive IP services over Mobile IP. The draft released by Hemant
Chaskar (Nokia Research Center) in February 2002, describes requirements for an IP
QoS mechanism for its satisfactory operation with Mobile IP.

There are four important steps involved in solving the QoS problem for Mobile IP. They
are as follows:

(1) List the requirements that Mobile IP places on the QoS mechanism.
(2) Evaluate current IP QoS solutions against these requirements.
(3) Decide if current solutions need to be extended, or if new ones need to be
defined.
(4) Depending on the result of step 3, define new solutions or fix the old ones.
The draft addresses only the requirements step i.e., (1).

6.5 Mobile IP service through MPLS

Multi-Protocol Label Switching is a technology that combines the simplicity of IP routing
with the high-speed switching of ATM. The draft by Jun Kyun Choi (ICU), Tai Won Um
(ICU), Yoo Kyoung Lee (ETRI), and Sun Hee Yang (ETRI) released in November 2001,
discusses how to build the large-scale Mobile IP network through the MPLS network.

One small-scale Mobile IP network could be connected to other networks through the
MPLS backbone network. It proposes the MPLS network architecture to provide the
large-scale Mobile IP network.

Specifically, it proposes that the label distribution protocols CR-LDP and RSVP-TE can be
applied to set up the label switched path (LSP) tunnels between the mobile agents (that
is, Foreign Agents and Home Agents). This means that one or more Label Switched
Paths (LSPs) on an MPLS network could replace the IP-in-IP tunnels.

6.6 AAA NAI for Mobile IPv4 Extension

When a mobile node moves between two foreign networks, it has to be re-
authenticated. If the home network has multiple AAA servers, the re-authentication
request may not be received by the same AAA server as previous authentication
requests.
Mobile IP Paresh Jain and Rakesh Kelkar Page 23 of 25

In order for the new AAA server to be able to forward the request to the correct HA, it
has to know the identity of the HA. The draft released by F. Johansson (ipUnplugged),
and T. Johansson (Ericsson) in March 2002, defines an extension that enables the HA to
pass its identity to the mobile node, which can in turn pass it to the AAA server when
changing the point of attachment.

6.7 Mobile IPv6 Drafts

6.7.1 Fast Handovers for Mobile IPv6

Mobile IPv6 describes how a Mobile Node can change its point of attachment from one
Access Router to another, a process referred to as handover. During this process, there
is a time period during which the Mobile Node is unable to send or receive IPv6 packets.
This time period is referred to as handover latency.

In certain scenarios, the handover latency resulting from standard Mobile IPv6 handover
procedures could be greater than what is acceptable to support real-time or delay-
sensitive traffic. The intent of the draft by G. Dommety, A. Yegin, C. Perkins, G. Tsirtsis,
K. El-Malki, and M. Khalil released in March 2002, is to describe protocol enhancements
that can be used to minimize handover latency, thereby making Mobile IPv6 better
equipped to support real-time traffic.

The following handover mechanisms are described:

! Anticipated Handover: Layer 3 initiates handover to the new Access Router while
the Mobile Node still has Layer 2 connectivity to the current Access Router. In this
scenario, either the Mobile Node or the current Access Router have predictive
information in advance of the actual Layer 2 handover about where the Mobile Node
will be moving, or the Mobile Node or current Access Router can actually force
handover to a particular new Access Router.

! Tunnel-based Handover: The Mobile Node defers Layer 3 handover until it is on the
new Access Router, or possibly later. The current Access Router tunnels packets to
the Mobile Node under its old care-of address until the Mobile Node performs Layer
3 handover. If the Mobile Node moves again without performing Layer 3 handover,
the tunnel is moved by the old and new Access Routers to accommodate the Mobile
Node's movement.

6.7.2 Localized Mobility Management Requirements for IPv6

The draft by Carl Williams (DoCoMo USA Labs) released in March 2002, describes
requirements for Localized Mobility Management (LMM) for Mobile IPv6. Localized
Mobility Management, in general, introduces Local Mobility Agent functionality (LMA).

LMA proxies a Regional care-of address that remains the same, while the mobile node
moves within a Local Mobility Domain. This reduces the binding update signalling
latency and the signalling load outside the Local Mobility Domain. LMM also serves as a
mechanism to hide the Mobile Node's location from observers outside the administration
domain (Local Mobility Domain).

6.7.3 Non-final Mobility Header for Mobile IPv6

Mobile IP Paresh Jain and Rakesh Kelkar Page 24 of 25

The draft released by Charles E. Perkins (Nokia Research Center), and Francis Dupont
(ENST Bretagne) released in April 2002, specifies operations to allow inclusion of data
along with a mobility header (from Mobile IPv6) containing a Binding Update or Binding
Acknowledgement message. The objective is smoother handovers and reduced jitter
and bandwidth utilization.

Such an operation was described in Mobile IPv6 specifications until concerns about
IPsec policy ambiguity led to a more restrictive approach towards verifying the
authentication data in the Mobility Header.

Interactions with IPsec-based verification of mobility messages are described.

Establishment of such IPsec-based methods preclude the use of the mobility header
specified in this document, unless simple modifications to IPsec (outside the scope of
the draft) can be utilized.

6.7.4 Mobile IPv6 support in MPLS Network

The draft released by Jun Kyun Choi (ICU), Myoung Hun Kim (ICU), and Yoon Ju Lee
(ETRI) in December 2001, discusses how to build the large-scale mobile IPv6 network
along with the MPLS network.

It proposes that Constraint-based Routing using Label Distribution Protocol and

Extensions to RSVP for Label-switched path (LSP) Tunnels (CR-LDP/RSVP-TE) can be
applied to set up Quality of Service guaranteed LSP tunnels between a Label Edge
Router (LER) of the mobile node and an LER of the correspondent node.

It means that the IPv6-in-IPv6 tunnels can be replaced by one or multiple LSPs on the
MPLS network. This follows design principles such as idle mobile node consideration and
QoS guarantee, smooth handoff, and no change of Mobile IPv6, etc.
Mobile IP Paresh Jain and Rakesh Kelkar Page 25 of 25

7 References
[1] “Combined GSM and Mobile IP Mobility Handling in UMTS IP CN”, 3GPP
TR23.923 version 3.0.0

[2] C. Perkins, Mobile IPv6 & Cellular Telephony

[3] Integration of Mobile IP and Multi-Protocol Label Switching, Zhong Ren

Chen-Khong Tham Chun-Choong Foo Chi-Chung Ko

[4] Mobility Support in IPv6, draft-ietf-mobileip-ipv6-16

[5] P.S0001-B, Wireless IP Network Standard version 1.0.0, February 2002,

3GPP2

[6] RFC 1256, ICMP Router Discovery Messages

[7] RFC 1321, The MD5 Message-Digest Algorithm

[8] RFC 1661, Point-to-Point Protocol

[9] RFC 2003, IP Encapsulation within IP

[10] RFC 2004, Minimal Encapsulation within IP

[11] RFC 2356, Sun's SKIP Firewall Traversal for Mobile IP

[12] RFC 2401, Security Architecture for the Internet Protocol

[13] RFC 2794, Mobile IP Network Access Identifier Extension for IPv4

[14] RFC 3220, IP Mobility Support for IPv4

[15] Route Optimisation in Mobile IP, draft-ietf-mobileip-optim-09