Internet DRAFT - draft-jeong-netlmm-dual-stack-moving
draft-jeong-netlmm-dual-stack-moving
Network Working Group S. Jeong
Internet-Draft ETRI
Expires: December 21, 2006 Y-H. Han
KUT
M-K. Shin
H-J. Kim
ETRI
June 19, 2006
Network-based Mobility Support for Dual Stack Nodes
draft-jeong-netlmm-dual-stack-moving-00
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 December 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo describes the network-based mobility support for dual stack
mobile nodes moving into an IPv4-only or an IPv6-only subnetwork
within a NETLMM domain. This memo also presents a network-based
global mobility management protocol with support of IPv4-IPv6
Jeong, et al. Expires December 21, 2006 [Page 1]
Internet-Draft Mobility Support for Dual Stack Nodes June 2006
traversal. By utilizing this document, mobile nodes can move from an
IPv4/IPv6 dual stack localized domain to an IPv6-only (or IPv4-only)
localized domain without any IP session disruption.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
4. Design Principles . . . . . . . . . . . . . . . . . . . . . . 7
5. Scenarios for Dual Stack Mobile Nodes . . . . . . . . . . . . 8
6. Protocol Specification . . . . . . . . . . . . . . . . . . . . 12
6.1. Scenario 1: Moving into an IPv4-only or IPv6-only
subnetwork within a NETLMM Domain . . . . . . . . . . . . 12
6.1.1. MN moves into IPv6-only subnetwork in a NETLMM
domain . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1.2. MN moves into IPv4-only subnetwork in a NETLMM
domain . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Scenario 2: Foreign NETLMM domain only supports IPv6 . . . 14
6.2.1. Binding Management . . . . . . . . . . . . . . . . . . 14
6.2.2. Protocol Operation . . . . . . . . . . . . . . . . . . 15
6.3. Scenario 3: Foreign Netlmm domain only supports IPv4 . . . 15
6.3.1. Binding Management . . . . . . . . . . . . . . . . . . 15
6.3.2. Protocol Operation . . . . . . . . . . . . . . . . . . 16
6.4. Dual Stack Mobile Node Specification . . . . . . . . . . . 17
6.5. AR Specification . . . . . . . . . . . . . . . . . . . . . 17
6.6. GMAP Specification . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Jeong, et al. Expires December 21, 2006 [Page 2]
Internet-Draft Mobility Support for Dual Stack Nodes June 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 management has been based on network intelligence
in existing and conventional telecommunication networks. That is,
mobility management has been handled through collaboration between
the network nodes.
Recently, the IETF NETLMM WG has launched standardization of network-
based IP mobility management in a localized domain network.
According to [I-D.ietf-netlmm-nohost-ps], some problems of the
existing IP-level protocols for localized mobility management are
summarized as follow: 1) change of host stack software, 2) complex
security associations between network nodes and hosts, and 3) lack of
supporting IPv4 and IPv6. Thus, the standardization result of IETF
NETLMM WG is expected to be the interoperable and scalable localized
mobility management protocol with no requirement of host stack
change. It will have a more modular architecture which is
independent of any other existing global mobility management
protocols.
It should be noted, however, that while one of NETLMM's goals is not
to require updates on the host software, some update is still
required for global mobility management. When a host moves across
localized domains, the host's software should execute its mobility
management protocol to handle global mobility. So, relying on adding
such software to a host will still limit the lack of widespread
deployment of new features. The size of a global mobility management
protocol stack is expected to be no less than a localized mobility
management protocol stack.
During the transition period from IPv4 to IPv6, it is likely that
there are heterogeneous localized domains deploying different IP
stacks on their network equipments. That is, in a localized domain,
we can find different subnetworks only supporting IPv4 or IPv6.
Also, it is expected that one localized domain deploys only IPv4,
while other domain deploys only IPv6. Even though the results of
NETLMM will support both IPv4 and IPv6, a host is expected to use
different protocols, e.g. MIPv4 and MIPv6, to maintain connectivity
while moving between such localized network domains deploying
different IP stacks. As mentioned in [I-D.ietf-mip6-dsmip-problem],
the burdens of implementation and operation, the inefficiency of
mobility management, and the impossibility of IP connection will
occur if different mobility protocols would be used simultaneously
Jeong, et al. Expires December 21, 2006 [Page 3]
Internet-Draft Mobility Support for Dual Stack Nodes June 2006
for global mobility management. Moreover, if a software upgrade to
each host is required to accommodate such mobility protocols, it will
further hinder the broad deployment of those protocols.
This document is aimed to address and solve the similar problems as
the ones proposed by both [I-D.ietf-netlmm-nohost-ps] and [I-D.ietf-
mip6-dsmip-problem]. It will describes the efficient support for
mobile nodes moving into an IPv4-only or IPv6-only subnetwork within
a NETLMM domain. It will also describes a network-based global
mobility management protocol with support of IPv4-IPv6 traversal. By
utilizing this document, mobile nodes can move from an IPv4/IPv6 dual
stack localized domain to an IPv6-only (or IPv4-only) localized
domain without any IP session disruption.
Jeong, et al. Expires December 21, 2006 [Page 4]
Internet-Draft Mobility Support for Dual Stack Nodes June 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 and revised
terminology given here:
o Global Mobility Management Protocol : Unlike Mobile IP, HIP, and
MOBIKE, the Global Mobility Management Protocol of this Document
is a mobility protocol used by network nodes to change the global,
end-to-end routing of packets for a mobile nodes. The purposes of
global mobility management protocol is to maintain session
continuity when movement causes a topology change of a NETLMM
domain.
o MNID : A mobile node's unique identifier. E.g., MAC address of
the mobile node's interface
o GMAP : A node in the network where a mapping between mobile node's
permanent address and the subnet-local temporary address is stored
and managed. GMAP may be used for purposes of rendezvous and
possibly traffic forwarding. It also handles the NETLMM domain
movment events of a mobile node. It registers the association of
a mobile node's permanent address with its domain-local temporary
address into Home GMAP. On behalf of a mobile node, that is, GMAP
itself manages its global mobility.
o Home GMAP : A node in the network where a mapping between a mobile
node's permanent address and the domain-local temporary address is
stored and managed. Home GMAP may be also used for purposes of
rendezvous and possibly traffic forwarding.
o AR (Access Router) : A router in a NETLMM Domain, which handles
the movement events of a mobile node, registers the association of
a mobile node with its point of attachment to a GMAP and provides
routing services to mobile nodes.
Jeong, et al. Expires December 21, 2006 [Page 5]
Internet-Draft Mobility Support for Dual Stack Nodes June 2006
3. Problem Statement
The problem statements used to motivate this document are similar to
both [I-D.ietf-netlmm-nohost-ps] and [I-D.ietf-mip6-dsmip-problem].
Among the all problems mentioned in the two documents, however, some
problems do not pertain to this document, while others are closely
connected to this document. The following lists such relevant
problems.
The first problem is that current global mobility management requires
updates to the host software, which hinders the broad deployment of
those protocols. Even though the end-to-end intelligence is the
design philosophy used in IETF, many mobile network operators have
pointed out that several problems caused by the end-to-end approach
are not suitable to realize the commercial carrier-grade All-IP
mobile network. NETLMM WG tries to eliminate such a software update
to a host by shifting the mobility management function from host to
access router. However, a software upgrade to a NETLMM-compliant
host is still required since it should support a global mobility
management protocol.
The second problem is that complex security associations between
network nodes and hosts are still required for the existing global
mobility management solutions, even though NETLMM solution is
utilized. In addition to the additional signaling required to set up
the security associations, provisioning a host with credentials for
roaming to all the localized domains will hinder the broad deployment
of the future All-IP mobile network.
The third problem is that existing mobility management protocols do
not simultaneously support both IPv4 and IPv6. So, the network
operator would need to have two separate GMAPs implementing different
protocols, each supporting IPv4 or IPv6, or make a GMAP support both
protocols. Network signaling messages, configuration information,
operational and implementation burdens would be doubled. In addition
to them, since the IPv4-IPv6 traversal is not supported by existing
mobility management protocols, a node moving to a new IPv4-only (or
IPv6-only) localized domain would not be able to maintain
connectivity of its IPv6 (or IPv4) applications. Recently, the MIP6
WG has adopted [I-D.ietf-mip6-nemo-v4traversal] for this purpose and
MIPv4 WG is considering a similar solution [I-D.tsirtsis-v4v6-mipv4].
However, it still requires an amount of updates to a host protocol
stack.
Jeong, et al. Expires December 21, 2006 [Page 6]
Internet-Draft Mobility Support for Dual Stack Nodes June 2006
4. Design Principles
The goal of this document is to provide a network-based global
mobility management protocol which supports v4-v6 traversal. The
protocol has following design principles.
o A host has an IPv4/IPv6 dual stack.
o A host does not have any mobility management protocol stack.
o A host does not have any protocol stack for v4-v6 traversal.
o An AR has IPv4/IPv6 dual stack.
o A GMAP has an IPv4/IPv6 dual stack.
o A localized domain (including home domain) deploys its networks by
using only IPv4 stack (or only an IPv6 stack).
o The expected solution of the NETLMM WG is used in a localized
domain.
Jeong, et al. Expires December 21, 2006 [Page 7]
Internet-Draft Mobility Support for Dual Stack Nodes June 2006
5. Scenarios for Dual Stack Mobile Nodes
If IPv6 is more widely deployed, dual stack nodes will move to dual,
IPv6-only or IPv4-only networks. It is reasonable to assume that
mobile nodes will move to networks that might not support IPv6 and
would therefore need the capability to support an IPv4 address. It
is unlikely that the mobile nodes will use IPv6 addresses only for
their connections. It is reasonable to assume that mobile nodes
will, for a long time, need an IPv4 address that can be used by
applications.
In [I-D.ietf-mip6-nemo-v4traversal], four scenarios were proposed for
dual stack moving nodes. At this phase, this draft considers a
subset of the scenarios in [I-D.ietf-mip6-nemo-v4traversal]. NAT-
traversal scenarios will be discussed later. Additionally, we
consider an intra-Netlmm domain moving scenario for dual stack nodes.
The scenarios considered in this draft are as follow.
All of the following scenarios assume that both the mobile node and
the Home GMAP are IPv4 and IPv6-enabled and that Network-based
Localized Mobility Management protocol is used within NETLMM domains.
We also assume that the Home GMAP is always reachable through a
globally unique IPv4 or IPv6 address.
Jeong, et al. Expires December 21, 2006 [Page 8]
Internet-Draft Mobility Support for Dual Stack Nodes June 2006
Scenario 1: Moving into an IPv4-only or IPv6-only subnetwork within a
NETLMM Domain
In this scenario, a mobile dual stack node moves to an IPv4-only or
IPv6-only subnetwork within a NETLMM domain.
/-----------\
/ Internet \
\ /
\-----+-----/
|
+-------+
| GMAP |
+---+---+
|
/------------+------------\
/ NETLMM \
\ domain /
/ \-------------------------/ \
| | |
+--+--+ +--+--+ +--+--+
| AR1 |v4/6 | AR2 |v4 | AR3 |v6
+-----+ +-----+ +-----+
/ \ / \ / \
/ \ / \ / \
+----+ +----+ +----+
| MN | --> | MN | --> | MN |
+----+ +----+ +----+
movement
Figure 1: Moving into an IPv4-only or IPv6-only subnetwork within a
NETLMM Domain
We also 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 December 21, 2006 [Page 9]
Internet-Draft Mobility Support for Dual Stack Nodes June 2006
Scenario 2: Foreign NETLMM domain supports IPv6-only
In this scenario, a mobile dual stack node moves to an IPv6-only
foreign NETLMM domain.
/-----------\
/ Internet \
\ /
\-----+-----/
|
+-------------+-------------+
| |
+-------+ +-------+
| GMAP | | GMAP |
+---+---+ +-------+
| |
/------+------\ /------+------\
/ NETLMM \ / NETLMM \
\ domain (v4/6)/ \ domain(v6) /
\-------------/ \-------------/
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| AR1 | | AR2 | | AR3 | | AR4 |
+-----+ +-----+ +-----+ +-----+
/ \ / \ / \ / \
/ \ / \ / \ / \
+----+ +----+
| MN | --> | MN |
+----+ +----+
movement
Figure 2: Foreign Netlmm domain only supports IPv6
In this scenario, the mobile node moves to an IPv6 Netlmm domain,
but, the mobile node might be communicating with an IPv4-only
application as well as an IPv6 application. So, 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 December 21, 2006 [Page 10]
Internet-Draft Mobility Support for Dual Stack Nodes June 2006
Scenario 3: Foreign NETLMM domain supports IPv4-only
In this scenario, a mobile dual stack node moves to an IPv4-only
foreign NETLMM domain.
/-----------\
/ Internet \
\ /
\-----+-----/
|
+-------------+-------------+
| |
+-------+ +-------+
| GMAP | | GMAP |
+---+---+ +-------+
| |
/------+------\ /------+------\
/ NETLMM \ / NETLMM \
\ domain (v4/6)/ \ domain(v4) /
\-------------/ \-------------/
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| AR1 | | AR2 | | AR3 | | AR4 |
+-----+ +-----+ +-----+ +-----+
/ \ / \ / \ / \
/ \ / \ / \ / \
+----+ +----+
| MN | --> | MN |
+----+ +----+
movement
Figure 3: Foreign Netlmm domain only supports IPv4
In this scenario, the mobile node moves to an IPv4 Netlmm domain,
but, the mobile node might be communicating with an IPv6-only
application as well as an IPv4-only application. So, 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 December 21, 2006 [Page 11]
Internet-Draft Mobility Support for Dual Stack Nodes June 2006
6. Protocol Specification
This section presents a specification of the network-based mobility
and IPv4-IPv6 traversal support protocol for each dual stack host
moving scenario which is shown in the previous section.
6.1. Scenario 1: Moving into an IPv4-only or IPv6-only subnetwork
within a NETLMM Domain
6.1.1. MN moves into IPv6-only subnetwork in a NETLMM domain
When a MN moves into a IPv6-only subnetwork within a NETLMM domain,
the MN will initiate a reachability test for the MN's IPv6 address by
transmission of a RS message. Since the AR2 has no state information
about the MN, it queries a GMAP in the NETLMM domain for information
about the MN.
The GMAP in the NETLMM domain sends the AR2 in the IPv6-only
subnetwork the MN's state information (e.g., IPv6 address, IPv4
address, and so on), so the AR2 can configure its routing table such
that traffic to the MN's IPv4 or IPv6 address will reach the MN
through AR2. The GMAP also informs the old AR so that it can clean
up the state about the MN. The operation between MN and AR should
follow the interface defined in [I-D.ietf-netlmm-mn-ar-if]. The AR2
updates its forwarding state and sends a RA message in order to
confirm MN's IPv6 address.
Figure 4 describes the binding update procedures when a MN moves from
AR1 to AR2 which supports IPv6 only.
MN AR2 GMAP AR1
| | | |
| |QUERY(MNID,MN's | |
| RS | IPv6 addr)| |
|------------>|--------------->| |
| | | |
| |REPLY(MNID,MN's |UPDATE(MNID,MN's|
| | IPv4 addr,| IPv4 addr, MN's|
| RA | MN's IPv6 addr)| IPv6 addr)|
|<------------|<---------------|--------------->|
| | | |
| | | |
Figure 4: MN moves into IPv6-only subnetwork in a NETLMM domain
When a GMAP in a NETLMM domain receives a packet destined to the MN's
IPv4 or IPv6 address, the GMAP knows that the MN has moved to AR2 by
looking up its forwarding state. The GMAP delivers the received
Jeong, et al. Expires December 21, 2006 [Page 12]
Internet-Draft Mobility Support for Dual Stack Nodes June 2006
packet to AR2 by using the NETLMM protocol which will be defined by
the NETLMM WG.
After receiving the packet sent from GMAP, AR2 recovers the original
packet which was sent from the CN. If the original packet is an IPv4
packet, AR2 looks up its IPv4 forwarding table and examines whether
the destination address of the IPv4 packet is in the IPv4 routing
table. If the original packet is an IPv6 packet, AR2 looks up its
IPv6 routing table. When the destination address of the original
packet is found in the IPv4 or IPv6 routing table, AR2 builds an L2
frame by using MNID and transmits it to the MN. The packet
transmission between the AR and MN will follow the solution of the
NETLMM WG.
6.1.2. MN moves into IPv4-only subnetwork in a NETLMM domain
When a MN moves into a IPv4-only subnetwork within a NETLMM domain,
the MN will initiate a reachability test for the MN's IPv4 address
according to [RFC4436] by transmission of a DHCP message. Since the
AR2 has no state information about the MN, it queries a GMAP in the
NETLMM domain for information about the MN. The rest of the binding
update procedures is similar to the 'MN moves into IPv6-only
subnetwork case' except that the AR2 replies to the MN trough a DHCP
reply message.
Figure 5 depicts the binding update procedures when a MN moves from
AR1 to AR2 which supports IPv4 only.
MN AR2 GMAP AR1
| | | |
| |QUERY(MNID,MN's | |
| DHCPREQUEST | IPv4 addr)| |
|------------>|--------------->| |
| | | |
| |REPLY(MNID,MN's |UPDATE(MNID,MN's|
| | IPv4 addr,| IPv4 addr, MN's|
| DHCPACK | MN's IPv6 addr)| IPv6 addr)|
|<------------|<---------------|--------------->|
| | | |
| | | |
Figure 5: MN moves into IPv4-only subnetwork in a NETLMM domain
Protocol operation for data transport is similar to the MN moves into
IPv6-only subnetwork in a NETLMM domain case.
Jeong, et al. Expires December 21, 2006 [Page 13]
Internet-Draft Mobility Support for Dual Stack Nodes June 2006
6.2. Scenario 2: Foreign NETLMM domain only supports IPv6
6.2.1. Binding Management
When a MN moves into a foreign NETLMM domain which supports IPv6
only, the MN will initiate a reachability test for the MN's IPv6 home
address by transmission of a RS message. Since the AR2 has no state
information about the MN, it queries a GMAP2 in the NETLMM domain for
information about the MN. The GMAP2 examines the MN's home address
and finds out that the address does not belongs to GMAP2's local
NETLMM domain. Thus, the GMAP2 queries the GMAP1 in the MN's home
NETLMM domain for information about the MN. We assume that the
address of the GMAP1 in the home NETLMM domain is given to the AR2 by
using link layer technology (out of scope of this document).
The GMAP1 in the home NETLMM domain sends the GMAP2 in foreign NETLMM
domain the MN's state information (e.g., IPv6 home link prefix
information, IPv6 home address, IPv4 home address, and so on), so the
GMAP2 can configure its routing table such that traffic to the MN's
IPv4 or IPv6 home address will reach the MN through AR2. The GMAP1
also informs the old AR so that it can clean up the state about the
MN.
The GMAP2 sends the AR2 the MN's state information. Then, the AR2
updates its forwarding state and sends a RA message to the MN with
the MN's IPv6 home link prefix included.
Figure 6 shows the binding management procedures when a MN moves from
home NETLMM domain (GMAP1) to foreign NETLMM domain (GMAP2) which
supports IPv6 only.
MN AR2 GMAP2 GMAP1 (Home GMAP) AR1
| | | | |
| |QUERY(MNID,IPv6 |QUERY(MNID,IPv6 | |
| RS | home addr)| home addr)| |
|------------>|--------------->|---- ---------->| |
| | | | |
| |REPLY(MNID,v6 HL|REPLY(MNID,v6 HL|UPDATE(MNID,IPv4|
| | prefix,v4 home,| prefix,v4 home,| home addr,IPv6|
| RA | v6 home addr)| v6 home addr)| home addr)|
|<------------|<---------------|<---------------|--------------->|
| | | | |
| | | | |
Figure 6: MN in foreign netlmm domain supports IPv6
Jeong, et al. Expires December 21, 2006 [Page 14]
Internet-Draft Mobility Support for Dual Stack Nodes June 2006
6.2.2. Protocol Operation
If the binding update is done according to the procedures in the
previous subsection, we can consider two protocol operation cases,
communicating with the CN via IPv4 and IPv6, respectively.
When a GMAP1 in the MN's home NETLMM domain receives a packet
destined to the MN's IPv4 or IPv6 home address, the GMAP1 knows that
the MN has moved to another NETLMM domain by looking up its
forwarding state. The GMAP1 encapsulates the received packet in an
IPv6 packet and delivers it to a GMAP2 in the MN's foreign NETLMM
domain. The source and destination address in the outer IPv6 header
are the addresses of GMAP1 and GMAP2, respectively.
The GMAP2 in MN's foreign NETLMM domain removes the outer IPv6 header
of the received packet and encapsulates the original packet in an
IPv6 packet again. The GMAP2 looks up its state information and sets
the source address in the outer IPv6 header to GMAP2's address and
the destination to the address of AR2 which the MN is connected to.
After that, GMAP2 sends the encapsulated packet to the AR2.
After receiving the packet sent from GMAP2, AR2 recovers the original
packet which was sent from the CN. We assume that AR2 has an IPv4/
IPv6 dual stack. If the original packet is an IPv4 packet, AR2 looks
up its IPv4 forwarding table and examines whether the destination
address of the IPv4 packet is in the IPv4 routing table. If the
original packet is an IPv6 packet, AR2 looks up its IPv6 routing
table. When the destination address of the original packet is found
in the IPv4 or IPv6 routing table, AR2 builds an L2 frame by using
MNID and transmits it to the MN. The packet transmission between AR
and MN will follow the solution of the NETLMM WG.
6.3. Scenario 3: Foreign Netlmm domain only supports IPv4
6.3.1. Binding Management
When a MN moves into a foreign NETLMM domain supports IPv4 only, the
MN will initiate a reachability test for MN's IPv4 home address
according to [RFC4436] by transmission of a DHCP message. Since the
AR2 has no state information about the MN, it queries a GMAP2 in the
NETLMM domain for information about the MN. The rest of the binding
update procedures are similar to Scenario 1 except that the AR2
replies to the MN trough DHCP reply message.
Jeong, et al. Expires December 21, 2006 [Page 15]
Internet-Draft Mobility Support for Dual Stack Nodes June 2006
Figure 7 describes the binding management procedures when a MN moves
from home NETLMM domain (GMAP1) to foreign NETLMM domain (GMAP2)
which supports IPv4 only.
MN AR2 GMAP2 GMAP1 (Home GMAP) AR1
| | | | |
| |QUERY(MNID,IPv4 |QUERY(MNID,IPv4 | |
| DHCPREQUEST | home addr)| home addr)| |
|------------>|--------------->|---- ---------->| |
| | | | |
| |REPLY(MNID,v4 HL|REPLY(MNID,v4 HL|UPDATE(MNID,IPv4|
| | prefix,v4 home,| prefix,v4 home,| home addr,IPv6|
| DHCPACK | v6 home addr)| v6 home addr)| home addr)|
|<------------|<---------------|<---------------|--------------->|
| | | | |
| | | | |
Figure 7: MN in foreign netlmm domain supports IPv4
6.3.2. Protocol Operation
If the binding update is done according to the procedures in the
previous subsection, we can consider two operation cases,
communicating with a CN via IPv4 and IPv6, respectively.
When the GMAP1 in the MN's home NETLMM domain receives a packet
destined to the MN's IPv4 or IPv6 home address, the GMAP1 finds out
that the MN is no longer in its NETLMM domain by looking up its
forwarding state. Hence, the GMAP1 encapsulates the received IPv4 or
IPv6 packet in an IPv4 header which includes the GMAP1's IPv4 address
in the source address field and the GMAP2's address in the
destination address field. Then, GMAP1 delivers the encapsulated
packet to a GMAP2 in the MN's foreign NETLMM domain.
The GMAP2 in the MN's foreign NETLMM domain decapsulates the received
packet and encapsulates the original packet in an IPv4 packet again.
The GMAP2 looks up its state information and sets the source address
in the outer IPv4 header to GMAP2's address and the destination to
the address of the AR2 which the MN is connected to. After that,
GMAP2 sends the encapsulated packet to the AR2.
An AR2 receives the packet and recovers the original packet which was
sent from the CN. Then, the AR2 transmits the original packet to the
MN according to the lookup result of the appropriate routing table
depending on the protocol version of the original packet. The packet
transmission between the AR and MN will follow the same solution of
the NETLMM WG.
Jeong, et al. Expires December 21, 2006 [Page 16]
Internet-Draft Mobility Support for Dual Stack Nodes June 2006
6.4. Dual Stack Mobile Node Specification
Mobile hosts are equipped with both an IPv4 and IPv6 stack. MN
utilizes link layer technology (out of scope of this document) in
order to give MN's MNID and home GMAP information to the AR when the
MN moves to a new NETLMM domain. Also, it should support the MN
specification in the protocol for NETLMM which will be specified by
the NETLMM working group.
6.5. AR Specification
When an AR receives a RS (or DHCP) message from a MN, the AR does not
discard the received message which includes an unknown address(i.e.,
MN's home address). The AR sends a QUERY message containing the
MNID, the MN's home address (IPv4 or IPv6), and the address of MN's
home GMAP to a GMAP in the local NETLMM domain.
The AR has an IPv4/IPv6 dual stack. When the AR receives a packet
encapsulating the original packet sent from the CN, it looks up the
appropriate forwarding table depending on the protocol version of the
original packet. For example, if the original packet is an IPv4
packet, the AR searches the IPv4 forwarding table in order to find
forwarding table entry for the MN. The AR also should support the AR
specification in the protocol for the NETLMM which will be specified
by the NETLMM working group.
6.6. GMAP Specification
If a foreign GMAP receives a QUERY message from an AR containing
MNID, the MN's home address, and the address of MN's home GMAP, it
sends a QUERY message to the MN's home GMAP. If the MN's home GMAP
receives a QUERY message from another GMAP, it replies with its state
information about the MN. The home GMAP also informs the old AR so
that it can clean up the state about the MN.
When the foreign GMAP receives a REPLY from the home GMAP, it
configures its routing table such that traffic to the MN's home
address will reach the MN through the AR2. The foreign GMAP also
sends the AR2 its state information about the MN. Both the home GMAP
and the foreign GMAP should support the MAP specification in the
protocol for NETLMM which will be specified by the NETLMM working
group.
Jeong, et al. Expires December 21, 2006 [Page 17]
Internet-Draft Mobility Support for Dual Stack Nodes June 2006
7. Security Considerations
Although NETLMM provides mobility support without any extra signaling
between a MN and network, it still requires mobility signaling for
the global mobility management. So, it is required to have extra
security association between each GMAP (and Home GMAP) and MNs.
However, this document describes an efficient protocol without any
such extra security association between a MN and a network entity.
Also removing MN involvement in localized and global 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. The security associations between network entities can be
built by static configuration or from other technologies, which will
be analyzed in the future version of this draft.
8. 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-mip6-dsmip-problem]
Soliman, H. and G. Tsirtsis, "Mobility management for Dual
stack mobile nodes A Problem Statement",
draft-ietf-mip6-dsmip-problem-01 (work in progress),
October 2005.
[I-D.ietf-mip6-nemo-v4traversal]
Soliman, H., "Mobile IPv6 support for dual stack Hosts and
Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-01
(work in progress), March 2006.
[I-D.tsirtsis-v4v6-mipv4]
Tsirtsis, G., "Dual Stack Mobile IPv4",
draft-tsirtsis-v4v6-mipv4-01 (work in progress),
April 2006.
[I-D.ietf-netlmm-mn-ar-if]
Laganier, J. and S. Narayanan, "Network-based Localized
Mobility Management Interface between Mobile Node and
Access Router", draft-ietf-netlmm-mn-ar-if-00 (work in
progress), April 2006.
[I-D.ietf-netlmm-nohost-req]
Kempf, J., "Goals for Network-based Localized Mobility
Management (NETLMM)", draft-ietf-netlmm-nohost-req-01
Jeong, et al. Expires December 21, 2006 [Page 18]
Internet-Draft Mobility Support for Dual Stack Nodes June 2006
(work in progress), April 2006.
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
Jeong, et al. Expires December 21, 2006 [Page 19]
Internet-Draft Mobility Support for Dual Stack Nodes June 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
Hyoung-Jun Kim
ETRI
161 Gajeong-dong, Yusung-gu
Daejeon, 305-350
Korea
Phone: +82 42 860 6576
Email: khj@etri.re.kr
Jeong, et al. Expires December 21, 2006 [Page 20]
Internet-Draft Mobility Support for Dual Stack Nodes June 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jeong, et al. Expires December 21, 2006 [Page 21]
