Internet DRAFT - draft-jeong-netlmm-dual-stack-moving-ps
draft-jeong-netlmm-dual-stack-moving-ps
Network Working Group S. Jeong
Internet-Draft ETRI
Intended status: Informational Y-H. Han
Expires: March 1, 2007 KUT
M-K. Shin
ETRI
P. Savola
CSC/FUNET
August 28, 2006
Problem Statement for Dual Stack Moving Internet (DSMI)
draft-jeong-netlmm-dual-stack-moving-ps-00.txt
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on March 1, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Jeong, et al. Expires March 1, 2007 [Page 1]
Internet-Draft Dual Stack Moving Problem August 2006
Abstract
This draft discusses the handover problem of dual stack mobile nodes
when the mobile nodes roam over IPv4 and IPv6 NETLMM domains.
Current NETLMM architecture supports IPv6 only. However, as the
NETLMM architecture being more widely used, it will be likely to
introduce the NETLMM architecture to IPv4 networks. In this
environment, a dual stack mobile node may move to both IPv6 and IPv4
NETLMM domains.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Handover Scenario for Dual Stack Mobile Nodes . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Jeong, et al. Expires March 1, 2007 [Page 2]
Internet-Draft Dual Stack Moving Problem August 2006
1. Introduction
The Internet is now evolving towards a commercial carrier-grade IP
network with appropriate QoS and security. Mobility management is
one of the important factors in realizing such a mature IP network.
Many proposals on IP mobility management for the Internet have
considered the use of end-to-end principles. However, it is well
known that mobility for IP nodes can be more efficiently supported if
mobility management is handled by network elements.
The IETF NETLMM WG has launched standardization of network-based
mobility management in a localized domain. According to
[I-D.ietf-netlmm-nohost-ps], problems of the existing host-based
solutions for localized mobility management are summarized as follow:
1) change of host stack software, 2) lack of supporting both IPv4 and
IPv6, and 3) additional security associations between network nodes
and mobile nodes. Network-based localized mobility management could
be one of the prominent ways to support IP mobility to mobile nodes,
because it requires no software on the mobile node.
In [I-D.ietf-netlmm-nohost-req], 12 goals for localized mobility
management are described. Among them, following goal is not achieved
yet.
o Support for IPv4 and IPv6 (Goal #9)
During the transition period from IPv4 to IPv6, it will be likely to
exist heterogeneous localized domains supporting different IP stacks.
That is, it is expected that some localized domains deploy IPv4-only,
while other domains supports IPv6-only. In this environment, a dual
stack mobile node may move to both IPv6 NETLMM domains and IPv4
NETLMM domains. Therefore, a new mobility management protocol is
required to maintain IP connectivity during a dual stack mobile
node's handover between IPv6 NETLMM domains and IPv4 NETLMM domains.
Jeong, et al. Expires March 1, 2007 [Page 3]
Internet-Draft Dual Stack Moving Problem August 2006
2. Terminology
Terminology in this document follows that in [RFC3753] and
[I-D.ietf-netlmm-nohost-ps], with the addition of some new and
revised terminology given here:
o Mobility Anchor Point (MAP) : A node in the network which manages
a mapping between mobile node's permanent address and the local
temporary address.
Jeong, et al. Expires March 1, 2007 [Page 4]
Internet-Draft Dual Stack Moving Problem August 2006
3. Problem Statement
Current network-based localized mobility management architecture
proposed by NETLMM WG supports IPv6 only. However, as the NETLMM
architecture being more widely used, it will be likely to introduce
the NETLMM architecture to IPv4 networks.
In this environment, a dual stack mobile node may move to not only
IPv6 NETLMM domains but also IPv4 NETLMM domains. When the dual
stack mobile node handovers between IPv6 NETLMM and IPv4 NETLMM
domains, it will be difficult to maintain IP connectivity.
Especially, maintaining IPv6 connectivity in IPv4 NETLMM domains or
IPv4 connectivity in IPv6 NETLMM domains is not supported.
Therefore, this suggests to design a mobility management solution for
federated NETLMM domains.
Current mobility management protocols (e.g., Mobile IP) may be
applied to the mobility management between heterogeneous NETLMM
domains. However, the mobile host-side stack requirement would
hinders the wide deployment of those mobility management protocols.
Also, location privacy problem may occur when the mobile node moves
to other NETLMM domains. The change in temporary local address as
the mobile node moves exposes the mobile node's topological location
to correspondents and potentially to eavesdroppers
[I-D.ietf-netlmm-nohost-ps].
Therefore, it is needed to develop a mobility management protocol
that supports mobile node's roaming over IPv6 and IPv4 NETLMM domains
with single IP address and does not require additional host-side
software update.
3.1. Handover Scenario for Dual Stack Mobile Nodes
The mobile node's movement scenario for federated NETLMM domains is
shown in Fig. 1. In the following handover scenario, we assume that
both the mobile nodes and the MAPs are IPv4 and IPv6-capable and that
the proposed protocol solution of NETLMM WG is used within a NETLMM
domain. We also assume that the MAPs are always reachable through a
globally unique IPv4 or IPv6 address.
In the handover scenario, the dual stack mobile node moves between an
IPv6-only NETLMM domain and IPv4-only NETLMM domain.
Jeong, et al. Expires March 1, 2007 [Page 5]
Internet-Draft Dual Stack Moving Problem August 2006
/-----------\
/ Internet \
\ /
\-----+-----/
|
+-------------+-------------+
| |
+-------+ +-------+
| MAP | | MAP |
+---+---+ +-------+
| |
/------+------\ /------+------\
/ NETLMM \ / NETLMM \
\ domain (v4) / \ domain(v6) /
\-------------/ \-------------/
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| AR1 | | AR2 | | AR3 | | AR4 |
+-----+ +-----+ +-----+ +-----+
/ \ / \ / \ / \
/ \ / \ / \ / \
+----+ +----+
| MN | <--> | MN |
+----+ +----+
movement
Figure 1: Handover between NETLMM domains supporting different IP
versions
In the scenario, the mobile node moves between the IPv6-only NETLMM
domain and IPv4-only NETLMM domain, but the mobile node might be
communicating with an IPv4-only application as well as an IPv6
application. Thus, we consider the following two cases of
applications for CN.
o case 1 : CN (Use of IPv4-only applications)
o case 2 : CN (Use of IPv6 applications)
Jeong, et al. Expires March 1, 2007 [Page 6]
Internet-Draft Dual Stack Moving Problem August 2006
4. IANA Considerations
There is no IANA consideration in this document.
Jeong, et al. Expires March 1, 2007 [Page 7]
Internet-Draft Dual Stack Moving Problem August 2006
5. Security Considerations
Although NETLMM protocol solution supports mobility without any extra
signaling between a mobile node and network, it still requires
mobility signaling for the handover between NETLMM domains. Thus, it
is required to have extra security association between a MAP and a
mobile node when handover between NETLMM domains occurs. Also,
removing mobile node's involvement in mobility management limits the
possibility of DoS attacks on network infrastructural elements
[I-D.ietf-netlmm-nohost-req]. IPSec can be applied to guarantee the
signaling messages exchanged by network entities.
Jeong, et al. Expires March 1, 2007 [Page 8]
Internet-Draft Dual Stack Moving Problem August 2006
6. References
[I-D.ietf-netlmm-nohost-ps]
Kempf, J., "Problem Statement for Network-based Localized
Mobility Management", draft-ietf-netlmm-nohost-ps-04 (work
in progress), June 2006.
[I-D.ietf-netlmm-nohost-req]
Kempf, J., "Goals for Network-based Localized Mobility
Management (NETLMM)", draft-ietf-netlmm-nohost-req-04
(work in progress), August 2006.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
Jeong, et al. Expires March 1, 2007 [Page 9]
Internet-Draft Dual Stack Moving Problem August 2006
Authors' Addresses
Sangjin Jeong
ETRI
161 Gajeong-dong, Yusung-gu
Daejeon, 305-350
Korea
Phone: +82 42 860 1877
Email: sjjeong@gmail.com
Youn-Hee Han
KUT
Gajeon-Ri 307 Byeongcheon-Myeon
Cheonan-Si Chungnam Province, 330-708
Korea
Email: yhhan@kut.ac.kr
Myung-Ki Shin
ETRI
161 Gajeong-dong, Yusung-gu
Daejeon, 305-350
Korea
Phone: +82 42 860 4847
Email: myungki.shin@gmail.com
Pekka Savola
CSC/FUNET
Espoo
Finland
Email: psavola@funet.fi
Jeong, et al. Expires March 1, 2007 [Page 10]
Internet-Draft Dual Stack Moving Problem August 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Jeong, et al. Expires March 1, 2007 [Page 11]
