JUNHYUK SONG
INTERNET DRAFT CHAEYOUNG CHONG
October 2001 SAMSUNG ELECTRONICS.
DONGKIE LEE
SK TELECOM
MIPv6 IP User mobility support through DNS
draft-song-mobileip-mipv6-user-mobility-00.txt
draft-song-mobileip-mipv6-user-mobility-01.txt
Status of This Memo
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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 months
and may be updated, replaced, or obsoleted by other documents at
any time. 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.
Abstract
The Mobile IP can provide IP mobility. The mobile node identified by
its Home Address can have transparent home IP routing service
regardless of attaching point. However the need for the user
mobility support has identified by wireless operators so as to
provide IP routing service, based on the user identifier not based on
home IP address. This document specifies the user mobility support
for Mobile IPv6 through DNS, while providing semi-secure binding
update mechanism for the route optimization between MN and CN.
1. Introduction
The demand for wireless mobile networking has been dramatically
increased thanks to rapid development of Wireless technology and
de facto Mobile IP technology. Mobile IP, as originally specified,
defines the protocol enhancements that can provide IP mobility over
the Internet. The mobile node, identified by its Home Address
regardless its attaching point can have transparent routing of IP
datagrams. However the need for the user mobility support has
identified by wireless operators so as to keep pace of nowadays
competitive wireless mobile industry. This document basically
specifies the user mobility support over mobile IPv6 signaling
through DNS location server, while achieving route optimization
between MN and CN by semi-secure binding update mechanism.
Since the NAI [3] is already used in Mobile IPv4, this document
presumes the Mobile IP NAI extension [2] will continue to serve in
Mobile IPv6 world to identify the users for Authentication,
Authorization, and Accounting service.
1.1 Goal
The goals of this document is to achieve IP user mobility for Mobile
IPv6 using DNS, while providing route optimization between MN and CN
by using semi-secure binding update mechanism.
1.2 Assumptions
This document assumes Home Agent/User Mobility Agent and Mobile Node
share the same secret key for binding update.
This document assumes Mobile IPv6 will support NAI destination option
for user identification purpose.
Detailed description of destination options, described in this
document and other protocol mechanism are outside scope of
this document and will be described in some other documents.
1.3 Applicability Statement
Mobile IPv6 provides IP mobility through IPv6 destination options and
IPv6 address autoconfiguration. This is useful for the specific
mobile terminal that change the point of attachment and CoA while
continue to receiving IP routing service directed to its home IP
address.
However, Mobile IPv6 itself doesn't facilitate the user mobility that
is highly required service in nowadays wireless communication
environment. The wireless operator wants to provide a subscriber
with a constant network reachability, which is any user can be always
locatable by user identifier, regardless of its point of attachment,
mobile node or IP address. The IP user mobility mechanism defined in
this document lets correspondent node to locate the user by user
identifier, and directly send IP packets to MN. The application for
IP user mobility service is such as IP push service, instant messaging
service and global roaming by User Identification Card (UIM), etc.
1.4 Terminology
This document frequently used the following terms:
User Mobility Agent (UMA)
A functional entity loaded into home agent which converts the
NAI into Fully Qualified Domain Name(FQDN) and dynamically
update the location of the user to the DNS server.
It may maintain the entry for user identifier(UI), matching
the current IP address of mobile node
User Identifier (UI)
The identifier made of concatenation of User ID and realm.
This is used for user authentication for access permission,
indicating current location of user.
User Binding Table
A cached table of User Mobility Agent which has entry made of
user identifier, current IP address, and lifetime.
2. Basic Operation
This section describes the basic operation of the IP user mobility
by mobile IPv6 signaling. When a user moves to new location or
mobile node configures new care of address (CoA), the user
MUST register its current location to UMA/HA by Mobile IP binding
update message. The binding update message will periodically
retransmit as described in "Mobility Support in IPv6" [6]
2.1 User Authentication generation
Upon receiving of Agent Advertisement from Mobile IPv6 router, Mobile
Node shall generate Binding Update message with *NAI option.
Mobile Node shall compute user identifier authentication from
following fields of IPv6 header and destination options.
It will provide user authentication and message integrity.
- Destination IP Address of the IPv6 header
- Care-of Address, in the Source IP Address of the IPv6 header
- Home Address, from the Home Address Destination option
(If available)
* NAI, from the NAI Destination option
- Option Type of the Binding Update destination option
- Option Length of the Binding Update destination option
- All flags of the Binding Update destination option
- Reserved field of the Binding Update option
- Authentication Data Length of the Binding Update
- Lifetime of the Binding Update destination option
- Security Parameters Index (SPI) of the Binding Update
- Sequence Number Field of the Binding Update
- The entire data from all Binding Update Sub-Options, if any
[NOTE] * marked are newly defined option.
The calculated authenticator shall be placed in the Authentication
Data field of Binding Update option.
2.2 User Location registration
Upon receipt of binding update message with new NAI destination
option. The User Mobility Agent in Home Agent shall check User
Identifier Authentication data which is placed in the Authentication
Data field of Binding Update option. User Mobility Agent shall
authenticate the binding update message according to SPI of the
binding update.
If the user authentication data is not valid, User Mobility Agent
MUST rejects the binding update and MUST send Binding Acknowledgement
with error code( ? Invalid User Authentication) in the status
field.
If the user authentication is successful, Mobile IP Home Agent shall
complete rest of the Mobile IP binding update process (sending
binding Ack, etc), then User Mobility Agent MUST convert NAI into
FQDN (Fully Qualified Domain Name) and shall send DNS update message
to DNS server for user location update. (See figure 1)
+------+ Agent +--------------+ +--------------+
| |Advertisement | | | |
| | | MIPv6 | Binding Update | MIPv6 |
| MN |<------------ | Router |---------------->| HA/UMA |
| |------------> | |<----------------| |
| |Binding Update| | Binding Ack | |
| | | | | |
| |<-------------| | | |
+------+ Binding Ack +--------------+ +--------------+
|
DNS |
Update |
v
+--------------+
| DNS server |
+--------------+
Figure 1: User Mobility
2.3 User connectivity by DNS server
MIPv6 capable correspondent node shall query of the user location
through DNS server to locate the most recent location of the
user. The MIPv6 host shall retrieve two records from DNS server
indexed by the user identifier (FQDN), one for home address of
mobile node and the other is current mobile node address (Mobile IPv6
CoA). If there is no previous cache for the location of the user,
MIPv6 host shall begin to transmit IP packets to home address of MN.
The IP data will deliver to MN by through HA as tunneled data.
Upon receiving of encapsulated IP data from HA, MN would know either
MIPv6 host currently didn't have the cached binding table for the
user and MN, or doesn't support the user mobility feature at all.
Otherwise, IP data should have delivered directly from MIPv6 host.
The mobile node MAY send binding update message to correspondent node
for the route optimization.
+------+ Agent +------------+ +--------------+
| | Advertisement(1)| | | |
| |<----------------| MIPv6 |Binding Update(3)| MIPv6 |
| MN |Binding Update(2)| Router |---------------->| HA/UMA |
| |---------------->| |<----------------| |
| |<----------------| |Binding Ack (5) | |
| |Binding Ack(6) | | | |
| | | |<----------------| |
| |<----------------| |Encapsulated IP | |
+------+ Encapsulated IP +------------+Packet (9) +--------------+
| ^ Packet (10) ^ ^
| | | |
| | | |
| | | |
| | IP traffic (12) +------------+ IP traffic (8) | |
| +----------------------| MIPv6 Host |---------------------+ |
+----------------------->| CN | |
Binding Update (11)+------------+ |
^ DNS |
| Update |
DNS | (4) |
Query | |
(7) | v
| +--------------+
+-------------------->| DNS server |
+--------------+
Figure 2: Binding update case
Upon receiving binding update message, the MIPv6 correspondent host
shall compares IP source address of binding update message with
previously retrieved the user records from the DNS server.
If the second record (CoA) matches with the source IP address of the
binding update message, correspondent node shall begin to sending IP
packets to MN directly. (see figure 2)
The retrieved record shall not match with the source IP address of
the binding update, if MN or user moved to new location right after
CN query to DNS server. In this case, the correspondent node MUST
continue to sending IP data to the home address of MN until the new
location of MN is located. CN shall wait until the previously
retrieved binding cache expires, and then CN shall query again for
the new location of the user. If the second record (CoA) matches
with the source IP address of the binding update message,
correspondent node shall begin to sending IP packets to MN directly.
3. Security Consideration
The secure communication between MIPv6 Correspondent host and DNS
server is outside scope of this document.
There is possible denial service attack to CN by bombarding the CN
with fake binding update message. The cached binding update table
MUST have reasonable lifetime so as to reduce the risk of the DOS
attack.
4. IANA Consideration
Requires new NAI MIPv6 option
Requires to use MIPv6 authentication suboption
5. Acknowledgement
Special thanks to Prof. Murali Venkatesh of Syracuse University.
References
[1] C. Perkins, Editor. "IP Mobility Support". RFC 2002. October
1996.
[2] Bernard Aboba and Mark A. Beadles "The Network Access
Identifier". RFC 2486. January 1999.
[3] Calhoun, P. and C. Perkins. "Mobile IP Network Access Identifier
Extension for IPv4", RFC 2794, January 2000.
[4] Calhoun, P. and C. Perkins. "Mobile IPv4 Challenge/Response
Extensions", RFC 3012, November 2000.
[5] J.H Song, C.Y Chong, DK Lee
"draft-song-network-user-mobility-00.txt"
[6] Pat R. Calhoun and C. Perkins. "Diameter Mobile IPv4
Application" draft-ietf-aaa-diameter-mobileip-07.txt
[7] David B. Johnson and C. Perkins. "Mobility Support in IPv6"
draft-ietf-mobileip-ipv6-14.txt
Questions about this memo can be directed to the authors:
JUNHYUK SONG
SAMSUNG ELECTRONICS.
Mobile Development Team
Network Systems Division
Phone: +82-31-779-6822
Email: santajun@lycos.co.kr
FAX: +82-31-7798769
CHAE YONG CHONG
SAMSUNG ELECTRONICS.
Mobile Development Team
Network Systems Division
Phone: +82-31-779-6822
Email: cychong@samsung.com
DONGKIE LEIGH
SK TELECOM
Core Network Development Team
Network R&D Center
Phone +82-2-829-4640
Email: galahad@netsgo.com
FAX:+82-2-829-4612