Internet DRAFT - draft-wan-mip6-nemo-routing
draft-wan-mip6-nemo-routing
Network Working Group C. Wan
Internet-Draft X. Qin
Expires: December 16, 2006 C. Ye
Huawei Technologies
June 14, 2006
Route management of mobile entity with an ipv6 home address roaming into
the ipv4 network
draft-wan-mip6-nemo-routing-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 December 16, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The current Mobile IPv6 and NEMO specification supports only IPv6.
As an extension, the DSMip6 protocol [v4traversal]defines how the
dual-stack mobile node roams in the ipv4 network. The dsmip6
protocol assumes that both home agent and mobile node supports mipv4
and mipv6 protocol. It also assumes that both the home agent and
mobile node have a configured ipv4 address. These assumptions do
Wan, et al. Expires December 16, 2006 [Page 1]
Internet-Draft v4traversal June 2006
work during many scenarios. However, as the ipv4 address is a scarce
resource in many counrties, some mobile nodes may not be able to get
configured ipv4 home addresses from their home agents. In this
scenario, a temporary ipv4 home address is more useful. This
document will focuse on this scenario.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of the solution . . . . . . . . . . . . . . . . . . . 5
4. FHA discovery . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Binding update . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Route management . . . . . . . . . . . . . . . . . . . . . . . 8
7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 10
7.1. Mobile entity consideration . . . . . . . . . . . . . . . 10
7.2. Home agent consideration . . . . . . . . . . . . . . . . . 10
7.3. Correspondent node consideration . . . . . . . . . . . . . 10
7.4. Foreign home agent consideration . . . . . . . . . . . . . 10
7.5. Foreign agent consideration . . . . . . . . . . . . . . . 10
8. Security considerations . . . . . . . . . . . . . . . . . . . 11
9. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Wan, et al. Expires December 16, 2006 [Page 2]
Internet-Draft v4traversal June 2006
1. Introduction
MIP6 and NEMO allow mobile entities to move away from its home
network while maintaining reachability and ongoing sessions, using an
IPv6 home address or prefix. However, since IPv6 is not widely
deployed, it is reasonable to assume that mobile nodes will move to
networks that might not support IPv6. To solve this problem,dsmip6
protocol is designed, The dsmip6 protocol assumes that HA and mobile
entity support both mip4 and mip6 protocol. The mobile node may have
no ipv4 home address. If the mobile node has no ipv4 home address,
the home agent will act as a DHCP server, and assign the mobile node
an ipv4 home address. This requires that the HA must have an ipv4
address pool.
As the ipv4 address is a scarce resource, some home agents may have
no ipv4 address pool. So some home agents may not be able to assign
an ipv4 home address to the mobile entity. At the same time, only
part of the global network will support both ipv4 and ipv6 protocols.
There are surely some networks that support only ipv6 protocol. HA
in these networks will not be able to support mip4 protocol. In
addition,if we assume that all mip6 home agents must support mip4
protocol, it means that the ipv6 network must support ipv4 protocol.
This is not reasonable. So there are three categories of scenarios
in the global network: [DS-PB]
In the first category, the home network is an ipv4/ipv6 mixed
network. The dual-stack mobile entity with at least an ipv6 address
roams into the ipv4 or ipv6 network.
In the second category, the dual-stack mobile entity with an ipv6
home address roams into the ipv4 network. The home network is an
ipv6 only network.
In the third category, the dual-stack mobile entity with an ipv4 home
address roams into the ipv6 network. The home network is an ipv4
only network.
The dsmip6 protocol is focusing on the first category of scenarios.
This document will focus on the second category of scenarios. The
second category of scenarios assmues that the mobile entity can not
get an stable ipv4 home address from its home agent. The mobile
entity supports both mip4 and mip6 protocols, thus it supports both
ipv4 and ipv6 protocols. The home agent does not support ipv4
protocol, and mip4 protocol.
Wan, et al. Expires December 16, 2006 [Page 3]
Internet-Draft v4traversal June 2006
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 RFC 2119
[STANDARDS].
This Document uses terminology defined in [TERMS]. In addition or in
replacement of these, the following terms are defined or redefined:
FHA
FHA is the alias of foreign home agent, a function entity that can
provide temporary ipv4 address for the mobile entity.
THOAv4
THOAv4 is the temporary ipv4 home address that mobile entity gets
from FHA.
ME
ME is the alias of mobile entity. ME may be a mobile node or a
mobile router defined in the mip4 and mip6 protocol.
Wan, et al. Expires December 16, 2006 [Page 4]
Internet-Draft v4traversal June 2006
3. Overview of the solution
In the scenarios of the second category, when the mobile entity roams
into an ipv4 network, it can get an ipv4 COA from foreign
agent[RFC3344]. To use mip4 protocol, the mobile entity must get an
ipv4 home address too. It is a problem that the mobile entity can
not get ipv4 home address from the home agent. To solve this
problem, a new facility is added in the network, called foreign home
agent (FHA), which is located in the ipv4/ipv6 mixed network. The
foreign home agent supports both mip4 and mip6 protocol [RFC3775] .
The foreign home agent has both ipv4 and ipv6 address pools. When
the mobile entity with an ipv6 only home network roams into an ipv4
only network, the foreign home agent temporarily assigns an ipv4 home
address to the mobile entity. The ipv4 home address is called
THOAv4. In the ipv4 network, the mobile entity registers the ipv4
COA got from FA to the FHA. The foreign home agent acts as a mip4
home agent of the mobile entity.FA considers FHA as mobile entity's
HA. An ipv4 tunnel is built between mobile entity and FHA,and the
ipv6 packets are transmitted over the tunnel. when mobile entity
sends/receives ipv6 packets to/from its home agent or correspondent
nodes, the ipv6 packet is encapsulated in the ipv4 tunnel. The home
agent and correspondent node do not know that the mobile entity is in
the ipv4 network. They will send ipv6 packets to the mobile entity.
when the ipv6 packets is routed to the FHA, the FHA will encapsulate
it into ipv4 packet, and send it to the mobile entity. the mobile
entity must send mip6 binding update to the home agent or
correspondent nodes. So it must get a ipv6 COA. As the ipv6 packet
from HA or correspondent node must be routed to FHA, the ipv6 COA
must be acquired from the FHA. The ipv6 COA may be mapped from the
THOAv4, or by other method.
There are 3 main problems in this framework to be solved, including
FHA discovery, registering, and routing.
Wan, et al. Expires December 16, 2006 [Page 5]
Internet-Draft v4traversal June 2006
4. FHA discovery
Mip6 protocol defines a dynamic home agent address discovery
mechanism. It allows the mobile entity to discover their home agent
by the anycast interface identifier to their home link's prefix.
When the mobile entity is in the ipv6 network, it can use this
mechanism to discover FHA. When the mobile entity is in the ipv4
only network, it can discover the foreign home agent's ipv4 address
through the domain name system. The mobile entity must be configured
with the name of the home agent.
There may be some other FHA discovery mechanisms. This document will
not discuss on the detail of FHA discovery mechanisms. The FHA
discovery mechanism is similar to the HA discovery mechanism which is
defined in the mip4 and mip6 protocols.
Though the FHA discovery mechanism is similar to the HA discovery
mechanism, There are some differences between them. The reply
message from the FHA includes not only the FHA's ipv4 and ipv6
address but also the THOAv4 address. As the mobile entity must
register ipv6 COA to the home agent or correspondent node, it must
get the ipv6 COA from the FHA. The ipv6 COA can be an ipv4-mapped
ipv6 address. It is mapped from the THOAv4 address. If the FHA
supports DHCPv6 protocol, it can assign an ipv6 COA to the mobile
entity.
In the mip6 protocol, there are two bootstrapping solutions called
integrated bootstrapping and split bootstrapping. There may be some
differences between mip6 bootstrapping solution and v4traversal
bootstrapping solution.This document will not focuse on this topic.
Wan, et al. Expires December 16, 2006 [Page 6]
Internet-Draft v4traversal June 2006
5. Binding update
There are two kinds of register procedures. One is the mip4 register
procedure, and the other is the mip6 binding update procedure.
In the mip4 register procedure, the mobile entity will register its
ipv4 care-of address to FHA. The mobile entity gets its ipv4 care-of
address from the foreign agent, and registers the ipv4 COA to FHA
according to mip4 protocol. The mobile entity may send the register
packets straightly, or the foreign agent will send the register
packets instead. The home address in the mip4 register packet is
THOAv4. After getting THOAv4 address from foreign home agent, the
mobile entity may roam back to ipv6 network. Then it will return its
THOAv4 address to the foreign home agent and the mip4 register will
expire.
In the mip6 binding update procedure, the mobile entity will send
binding update message to its ipv6 home agent or correspondent node.
There are two kinds of mechanisms. One is normal mip6 binding
updates procedure. The mobile entity sends the binding updates to
the home agent or correspondent node. The only difference is that
the binding update messages are encapsulated over the IPv4 network.
The other is proxy register. When using the proxy register
mechanism, the mobile entity will not send register packet to the
home agent. The foreign home agent will send it instead. To use the
proxy register mechanism, a security alliance will need to be built
between FHA and HA.
In the mip4 register procedure, both mobile node and mobile
router[RFC3963] will send mip4 register. In the mip6 binding update
procedure, the mobile node will send mip6 binding update and the
mobile router will send NEMO binding update.
Wan, et al. Expires December 16, 2006 [Page 7]
Internet-Draft v4traversal June 2006
6. Route management
From the HA and CN perspective, the packet sent to/by the mobile
entity are ipv6 packets. The ipv6 packets may include mip6 signaling
information. But in the ipv4 network, the ipv6 packet is
encapsulated in the ipv4 packet. There is a tunnel between FHA and
mobile entity.
In the sending data procedure, the mobile entity will send ipv6
packets to the correspondent nodes or home agent over ipv4 network.
The ipv6 packets are encapsulated into ipv4 packets on the mobile
entity. The source address of the ipv4 packets is the THOAv4
address, and the destination address of the ipv4 packets is the ipv4
address of FHA. After encapsulating, the mobile entity will send the
packets according to the mip4 protocol. The foreign agent will route
it to FHA. If there is source address filtering problem, the foreign
agent should support Reverse Tunneling[RFC2344] for mobile ip. When
the FHA received the ipv4 packets from the mobile entity, it will
route the ipv6 packets which is decapsulated from the ipv4 packets to
the correspondent nodes or the home agent.
In the receiving data procedure, the ipv6 packets from the
correspondent nodes or home agent are routed to FHA. This is because
the ipv6 COA included in the binding update packets sent to the home
agent or correspondent nodes is assigned by FHA which is defined in
the FHA discovery section. FHA will encapsulate the ipv6 packets
into ipv4 packets. The source address of the ipv4 packets is the
ipv4 address of FHA, and the destination address of the ipv4 packets
is the THOAv4 of the mobile entity. After encapsulating,FHA will
send the ipv4 packets over the tunnel between HA and FA/MN according
to the mip4 protocol. Here FHA operation is similar to mip4 HA, it
will tunnel packets to foreign agent or mobile entity. When mobile
entity receives the ipv4 packets, it will decapsulate the ipv4
packets. Thus the mobile entity gets the ipv6 packets from
correspondent nodes or home agent which are encapsulated in the ipv4
packets.
Figure 1 is the route method when mobile entity uses bi-directional
tunneling mode. Figure 2 is the route method when mobile entity uses
route optimization mode.
Wan, et al. Expires December 16, 2006 [Page 8]
Internet-Draft v4traversal June 2006
ipv6 network | ipv4/ipv6 mixed network | ipv4 network
| |
CN HA | FHA | FA MN
| | | | | | |
|----->|------|---------->|---------------|--------->|------->|
| | | | | | |
|<-----|<-----|-----------|<--------------|----------|--------|
| | | | | | |
| | | | | | |
Figure 1: v4 traversal of bi-directional tunneling
ipv6 network | ipv4/ipv6 mixed network | ipv4 network
| |
CN | FHA | FA MN
| | | | | | |
|------|------|---------->|---------------|--------->|------->|
| | | | | | |
|<-----|------|-----------|<--------------|----------|--------|
| | | | | | |
| | | | | | |
Figure 2: v4 traversal of route optimization
If the mobile entity is a mobile router, it acts as an ipv6 mobile
router and an ipv4 mobile node. The ipv6 packets sent to/by the
mobile router will be encapsulated in the ipv4 tunnel defined as the
said.
Wan, et al. Expires December 16, 2006 [Page 9]
Internet-Draft v4traversal June 2006
7. Protocol Operations
7.1. Mobile entity consideration
In the FHA discovery procedure, mobile entity may get FHA information
and THOAv4 by the anycast method or DNS method. After mobile entity
gets its THOAv4 address, it must register to FHA termly. In the ipv4
network, mobile entity will encapsulate ipv6 packets sent to HA or CN
into ipv4 packets.
7.2. Home agent consideration
The home agent needs to support only mip6 protocol. It does not know
that the mobile entity has roamed into an ipv4 network.
7.3. Correspondent node consideration
The correspondent node needs to support only mip6 protocol. It does
not know mobile entity has roamed into an ipv4 network.
7.4. Foreign home agent consideration
The foreign home agent must be able to accept registers from mobile
entity, and it must be able to allocate tHOAv4 for mobile entity. In
the ipv4 network, the foreign home agent acts as a mip4 home agent.
In the ipv6 network, the foreign home agent acts as a mip6 access
router. The foreign home agent will encapsulate the ipv6 packet sent
to mobile entity into ipv4 packet and route the ipv4 packet to the
mobile entity. The foreign home agent will decapsulate the ipv4
packet from mobile entity into ipv6 packet and route the ipv6 packet
to the correspondent node. In the proxy register procedure,the
foreign home agent may also send register message to the home agent
of mobile entity instead of the mobile entity.The foreign home agent
may be a extension function of the dual-stack home agent defined in
[v4traversal], or a independent facility. The foreign home agent is
a logic entity.
7.5. Foreign agent consideration
The foreign agent needs to support only mip4 protocol. It acts as a
conventional mip4 foreign home agent.
Wan, et al. Expires December 16, 2006 [Page 10]
Internet-Draft v4traversal June 2006
8. Security considerations
Security is an end to end solution. When the mobile entity
communicates with the correspondent node or home agent, it uses the
security mechanism defined in the mip6 protocol[RFC3776]. When the
mobile entity communicates with the foreign home agent or foreign
agent, it uses the security mechanism defined in the mip4 protocol.
When the mobile entity uses the proxy register mechanism, there must
be a security association between FHA and HA.
9. Normative References
[DS-PB] "Scenario analysis and problem statement of the dual-stack
mobile entity roaming in the ipv4 and ipv6 network",
June 2006.
[RFC2344] "Reverse Tunneling for Mobile IP", May 1998.
[RFC3344] "IP Mobility Support for IPv4", August 2002.
[RFC3775] "Mobility Support in IPv6", June 2004.
[RFC3776] "Use of MIPv6 in IPv4 and MIPv4 in IPv6 networks",
June 2004.
[RFC3963] "Network Mobility (NEMO) Basic Support protocol", January
2005.
[STANDARDS]
"Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, October 1997,
<ftp://ftp.isi.edu/in-notes/rfc2119.txt>.
[TERMS] "Mobility Related Terminology", June 2004,
<ftp://ftp.isi.edu/in-notes/rfc3753.txt>.
[v4traversal]
"Mobile IPv6 support for dual stack Hosts and Routers
(DSMIPv6)", ???.
Wan, et al. Expires December 16, 2006 [Page 11]
Internet-Draft v4traversal June 2006
Authors' Addresses
Changsheng Wan
Huawei Technologies
Site A,Floor 10,HuiHong Mansion,No.91 BaiXia Rd.
Nanjing, China 210001
Phone: +86-25-84565415
Email: wanchangsheng@huawei.com
Xia Qin
Huawei Technologies
Site A,Floor 10,HuiHong Mansion,No.91 BaiXia Rd.
Nanjing, China 210001
Phone: +86-25-84565414
Email: alice.Q@huawei.com
Chengping Ye
Huawei Technologies
Site A,Floor 10,HuiHong Mansion,No.91 BaiXia Rd.
Nanjing, China 210001
Phone: +86-25-84565414
Email: yechengping@huawei.com
Wan, et al. Expires December 16, 2006 [Page 12]
Internet-Draft v4traversal 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.
Wan, et al. Expires December 16, 2006 [Page 13]
