Internet DRAFT - draft-goswami-mip4-peer-signaling
draft-goswami-mip4-peer-signaling
INTERNET-DRAFT Subrata Goswami
Expires August 06, 2005 February 7,2005
IPv4 Mobility through Peer Signaling
<draft-goswami-mip4-peer-signaling-00.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
monthsand may be updated, replaced, or obsoleted by other documents
at anytime. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights."
"This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Abstract
This document describes a way to perform mobility in IPv4
(potentially IPv6) without requiring any new entity in networks
Goswami 1
IPv4 Mobility through Peer Signaling February 2005
infrastructure (e.g. Home Agent, Foreign Agent, etc.). Instead of
using infrastructure entities this method delegates all the mobility
function to the end nodes. The method relies on source and
destination address translation at the end nodes, and signaling
between end nodes to perform hand offs - all these function can be
encapsulated in an entity called Mobility Agent (MA) in the end
nodes.
1. Overview and Rationale
Mobile IPv4 [MIP4] protocol makes use of 2 new entities per subnet,
Home Agent (HA) and Foreign Agent (FA). In addition, the mobile end
node (MN) needs to be instrumented. HA and FA, by being routers
requires substantial resources [Mipv4Ana]. Moreover the legacy end
nodes need to upgraded for Mobile IPv4. In this draft a new method
is proposed that involves a single agent, called Mobility Agent
(MA), in each end node that performs the functions of routing and
signaling for mobility.
The end nodes in IP networks tend to be computers with fair amount
of resources ( probably an effect of the end-to-end principle of
IP). In recent years for security reasons the end nodes have been
forced to be upgraded rapidly - which has resulted in streamlined
process and delivery infrastructure for software upgrades. Hence
upgrades of endnode is no longer a daunting task that once it used
to be.
Most end nodes permit some software based approaches to modify
traffic between the IP stack and the interface (e.g NDIS in Windows,
Netfilter in Linux , etc). Hence inserting a Mobility Agent below
the IP stack is straight forward process.
2. Network Architecture
A hypothetical IP network is shown in the following figure. The
mobile client MN can move from subnet X1 to X2 while connected
to CN ( for sake of brevity it is considered to be static).
[MN/MA] -----[X1]-----------
|
| [Internet]----[CN/MA]
v |
----[X2]-----------
Goswami 2
IPv4 Mobility through Peer Signaling February 2005
[MN] - Mobile Node
[CN] - Correspondent Node
[MA] - Mobility Agent
[X] - IP Router
Figure 1: IP Network
When the MN moves from X1 to X2, its IP address will change, from
say ipx1 to ipx2, which would result in the following. The CN would
still use ipx1 as destination address for all outgoing packets,
which would result in all packets sent to subnet X2. CN also will
look for ipx1 at source address for any previously setup transport
protocol sessions (e.g TCP or UDP, as SCTP accommodates multi-
homing there might be ways to handle such changes). On the MN
side,it now has a new IP address, ipx2, but transport protocols
are still using ipx1, hence no packet will go out of MN.
The MA, hides these address changes from transport protocols and
does an on the fly translation of src and dst IP addresses of
similar to NAT.
3. Signaling Message Sequence
The following figure shows the what happens when MN move from X1
to X2. After detecting subnet change, MN (though the resident MA )
sends a Subnet Change request message to CN. How subnet changes are
detected is beyond the scope of this document. The CN ( again
through the resident MA) sends a Change Challenge Request message to
both old and new addresses. On receiving this challenge request, the
MN send a response message. Now, if the CN receives two responses
from the old and the new IP addresses, then it considers the request
as spoofed and sends a Request Denied response to X1 subnet.
MN(X1) MN(X2) CN
<----------------- data -------------------->
---- (move) ---
(detect sunbet
change)
----- Subnet Change Request -->---
----- Subnet Change Chlg. Req -<--
AND
Goswami 3
IPv4 Mobility through Peer Signaling February 2005
------------------ Subnet Change Chlg. Req -<--
----- Subnet Change Chlg. Rsp.->--
------------------ Subnet Change Chlg. Rsp.->-- (implies spoofing)
----- Subnet Change Response --<-- (Request Allowed)
OR
------------------ Subnet Change Response --<-- (Request Denied,
spoofed)
<---- data -------------------->
Figure 2. Signaling Message Sequence
4. Signaling Message Format
The signaling messages have the following format as described in
detail below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CN Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ... |
| ( variable length ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. Signaling Message Format
4.1 Subnet Change Request
Goswami 4
IPv4 Mobility through Peer Signaling February 2005
This message is sent from MN to a CN after detection of subnet
change has been made. The Type field contains 1. The Initial IP
Address is the IP address seen by the transport layer. The New IP
Address is the new IP address obtained by the MN interface. The CN
address field is copied from the Destination Address of the IP
header. The New IP address should match the IP address of the
interface through which the message is going out. The
identification field is a 64 bit field supplied by the CN to the
MN. This should be set to 0 when the MN does not have one.
4.2 Subnet Change Allowed
This message is sent from CN to an MN after a Subnet Change
Request has been made. The Type field is 2. The Initial and New
Address fields contain the corresponding IP addresses of the MN as
in the request message. The CN address field is the address of the
CN interface through which the Subnet Change Request message came
in. The identification field is a 64 bit field supplied by the CN to
the MN. This should be a new number generated by CN when the
Subnet Change Request Identification field is 0. The MA in CN should
check for if it has all ready provided an identification to the
Initial IP address of the MN. This message is sent to the New IP
address.
4.3 Subnet Change Denied
This message is sent from CN to an MN after detection of
Subnet Change Request has been made. The Type field is 10. The Old
and New Address fields contain the corresponding IP addresses of
the request message. The CN address field is the address of the CN
interface through which the Subnet Change Request message came in.
The identification field is a 64 bit field supplied by the CN to
the MN. This should be a new number generated by CN when the Subnet
Change Request Identification field is 0. The MA in CN should check
for if it has all ready provided an identification to the Old IP
address of the MN. This message is sent to the New IP Address
stored in the CN for the corresponding Initial IP Address
4.4 Subnet Change Challenge Request
(To be described.)
4.5 Subnet Change Challenge Response
(To be described.)
The transport protocol for signaling messages for the Peer Mobility
method can be UDP based or ICMP based (To be described).
5. Mobility Agent in IP End Nodes
Goswami 5
IPv4 Mobility through Peer Signaling February 2005
A Mobility Agent (MA) is resident in both the mobile node and the
correspondent node that participates in IPv4 mobility.
5.1 Location of the Mobility Agent.
The MA could be resident between the Transport Layer and the
Network Layer or between the Network Layer and the Link Layer. It is
more popular and there exists well known interfaces to place
extensions between the Network Layer and the Link Layer of an IP end
node. Hence we will consider implementation implication for this
approach. The following figure shows a logical view of such an MA.
Transport Layer (TCP/UDP)
|
IP Stack --- (Routing Table)
|
Mobility Agent --- (Translation Table)
|
Interface --- (ARP Cache)
|
MAC
|
PHY
5.2 Mobility Agent State Machines
CN Signal Handling
[Start]<------------------------------------------|
| |
| (Subnet Change Request Message) |
| |
[Challenge Request ]--error ->-----------------------|
| |
| (Subnet Change Challenge Resp) |
| |
[Update Translation Table]---------------------------|
MN Signal Handling
Goswami 6
IPv4 Mobility through Peer Signaling February 2005
[Start]<------------------------------------------|
| |
| (Movement Detection) |
| |
[Update Translation Table ]--error ->----------------|
| |
| (Subnet Change Challenge Request) |
| |
[Challenge Response ]--error ->----------------------|
| |
| (Subnet Change Allowed) |
| |
[Update Translation Table]---------------------------|
CN/MN Packet Handling
[Start]<------------------------------------------|
| |
| ( Receive IP packet) |
| |
[Translate IP addresses] --error ->[Error Msg. toTransport]-|
| |
| |
| |
[Send IP Packet to Layer 2 Interface]------------------|
5.3 Mobility Agent Translation Table
The MA maintains a logical table that supports IP address
translations. The following figures shows the essence of such a
table.
Trans IP | New IP | Identification | Interface|
---------------------------------------------------
ip1 | ipn1 | xxxxxx | if0
The Translation Table contains the following IP addresses:
i. The Tranport Layer IP Address.
ii. The Transport Layer Gateway IP Address.
iii. The Transport Layer DNS Server IP Address.
ii) and iii) are required because the transport layer is unaware
of any change in the IP subnet. The Routing Table willl contain the
Transport IP Addresses, whereas the ARP Cache will contain the New
IP addresses.
Goswami 7
IPv4 Mobility through Peer Signaling February 2005
6. Security Considerations
Spoofing of Subnet Change Request has been handled by sending
Subnet Change Challenge request Message to both Old and New subnets.
7. IANA Considerations
This method specifies several new number spaces for values to be
used in various message fields. These number spaces include the
following:
8. Acknowledgments
9. References
[MIPv4] Perkins, C., "IP Mobility Support IPv4, revised", RFC
3344bis, June 2004.
[MIpv4Ana] IETF, draft-goswami-mobileip-analysis-v4-00.txt,
September 2002.
10. Author's Address
Subrata Goswami, Ph.D.
Fremont, CA 94539
sgoswami@umich.edu
This document expires August 07, 2005.
Goswami 8
