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]