[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

NGTRANS WG                                             Shiao-Li Tsao
Internet Draft                                             CCL, ITRI
Document: draft-ietf-ngtrans-moving-01.txt           George Tsirtsis
Category: Informational                         Flarion Technologies
Expires: September 2002                               Wolfgang Boehm
                                                             Siemens
                                                          March 2002

             Moving in a Dual Stack Internet
             <draft-ietf-ngtrans-moving-01.txt>


   Status of this Memo

      This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   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

   This document provides an analysis of the requirements to support
   mobility in a dual stack network. In this document, combinations
   of IPv4, IPv6, and dual stack mobile node moving in IPv4, IPv6, and
   dual stack networks are listed and the requirements to support
   mobility under different network and mobile node configurations are
   investigated. This document aims to reassess next generation
   transition (NGTRANS) tools from the point of view of mobility.

1. Introduction

   Mobile IP (MIP) is capable of offering IP mobility to hosts. Mobile
   IPv4 (MIPv4) [1] was designed for Internet Protocol version 4 (IPv4)
   and mobile IPv6 (MIPv6) [2] has been also defined for IPv6.
   Considering IPv4 to IPv6 transition, a number of protocols and
   mechanisms are proposed to facilitate IPv4/IPv6 communication in a
   transition network for different purposes or under different
   assumptions.




<Tsao, Tsirtsis, Boehm>       1

                <draft-ietf-ngtrans-moving-01.txt>         <March, 2002>

   [3] gives an overview of transition mechanisms within
   IETF NGTRANS working group. However, these transition mechanisms
   assume that hosts attach to the network statically. As for mobile
   nodes (MN) roaming in IPv4/IPv6 transition networks, impacts to
   these mechanisms have not been investigated.

   In this document, the requirements to support mobility in a dual
   stack network are analyzed. Combinations of mobile nodes moving
   in networks with various configurations are first listed and then
   mechanisms to support handoffs in different scenarios are examined.
   This document does not introduce new protocols and mechanisms, but
   recommend implementations and configurations for some specific
   handoffs. The principles behind this analysis are to maintain the
   existing connections of mobile nodes after handoff as much as
   possible, and to maximize accessibility to the visited networks.
   Moreover, tunneling mechanism is preferred rather than translators
   due to security concerns. Finally, route optimization issues are also
   addressed.

2. Terminology

   IPv4-only network
   A network that only implements IPv4. It can understand and process
   IPv4 packets and MIPv4 messages but can not understand IPv6 and
   MIPv6.

   IPv6-only network
   A network that only implements IPv6. It can understand and process
   IPv6 packets and MIPv6 messages but can not understand IPv4 and
   MIPv4.

   Dual stack network (DS network)
   A network that implements both IPv4 and IPv6. It can understand and
   process both IPv4/IPv6 packets and MIPv4/MIPv6 messages.

   IPv4-only mobile node (IPv4-only MN)
   A node that implements IPv4, MIPv4 and can be reached by an IPv4
   address.

   IPv6-only mobile node (IPv6-only MN)
   A node that implements IPv6, MIPv6 and can be reached by an IPv6
   address.

   Dual stack mobile node with an IPv4 address (DS MNv4)
   A node that has IPv4/IPv6 dual stack and an IPv4 address. The node
   can change its point of attachment from one link to another, while
   still being reachable via its IPv4 address.

   Dual stack mobile node with an IPv6 address (DS MNv6)
   A node that has IPv4/IPv6 dual stack and an IPv6 address. The node
   can change its point of attachment from one link to another, while
   still being reachable via its IPv6 address.

   Dual stack mobile node with an IPv4 and an IPv6 address (DS MN)
   A node that has IPv4/IPv6 dual stack and an IPv4 address and an IPv6
   address. The node can change its point of attachment from one link
   to another, while still being reachable via its IPv4 or IPv6 address.

 <Tsao, Tsirtsis, Boehm>       2

                <draft-ietf-ngtrans-moving-01.txt>         <March, 2002>


   IPv4-compatible IPv6 address
   An address of the form 0::0:a.b.c.d which refers to an IPv6/IPv4 node
   that supports automatic tunneling.

3. Combinations

   Table 1 lists all combinations of mobile node and its located
   networks. The located network means the network the mobile node
   settles. It might be MN's home network or a visited network. The
   definitions of the categories of mobile nodes and networks can
   refer to the terminologies defined in the previous section. For
   example, Combination 1 is an IPv6-only mobile node staying in an
   IPv6-only network. The case of a MN with both IPv4 and IPv6 address
   (DS MN) is not in the list since the MN can perform MIPv4 and
   MIPv6 procedures separately depending on the networks it locates.
   Regarding of interchanging information between MIPv4 and MIPv6
   for a DS MN, it is not coverred in this document. Among twelve
   combinations, Combination 2 and Combination 5 result in the loss of
   connectivity to the network. In the next section, handoff scenarios
   based on the remaining 10 combinations are examined.


   Table 1. List of combination of mobile node and its Located networks
   ----------------------------------------------------
   Combination  Mobile Node     Located Network
   ----------------------------------------------------
    1           IPv6-only       IPv6-only
    2(*)        IPv4-only       IPv6-only
    3           DS MNv6         IPv6-only
    4           DS MNv4         IPv6-only
    5(*)        IPv6-only       IPv4-only
    6           IPv4-only       IPv4-only
    7           DS MNv6         IPv4-only
    8           DS MNv4         IPv4-only
    9           IPv6-only       DS Network
    10          IPv4-only       DS Network
    11          DS MNv6         DS Network
    12          DS MNv4         DS Network
   ----------------------------------------------------
(*)loss of network connectivity

4. Handoff Scenarios

   In this section, procedures and mechanisms to fulfill handoffs are
   examined. Here, handoff is defined as a MN moving from one network to
   another network. The handoff procedures include the registration of
   MN's care-of address (COA) to its home agent and the maintenance of
   the existing connections, said native connections, to its
   correspondent nodes (CN). The emphases of this document are the MIP
   registration process and the maintenance of the native connections
   between MN and its CNs during handoff.




<Tsao, Tsirtsis, Boehm>       3

                <draft-ietf-ngtrans-moving-01.txt>         <March, 2002>


4.1 Handoffs of IPv6-only MN

   Table 2. List of handoffs of IPv6-only MN and mechanisms can be
   applied to the communications with CNs.
   ---------------------------------------------------------
   From Network To Network      IPv4-only CN    IPv6-only CN
   ---------------------------------------------------------
   IPv6-only    IPv6-only       TR              NA6
   IPv6-only    DS              TR              NA6
   DS           IPv6-only       TR              NA6
   DS           DS              TR              NA6
   ---------------------------------------------------------
   TR  : Translator mechanisms such as SIIT and NAT-PT
   NA6 : Native IPv6

   For IPv6-only MN, there are four handoff scenarios. That is, from an
   IPv6-only network to another IPv6-only network, from an IPv6-only
   network to a DS network, from a DS network to an IPv6-only network,
   and from a DS network to another DS network. Table 2 also lists all
   handoff scenarios and mechanisms can be used for the communication
   with CNs. While moving to a visited IPv6-only or DS network, IPv6-
   only MN can send MIPv6 messages to its home agent to perform MIP
   registration. After registration, the mobile node can be reached by
   its IPv6 address in a visited network. Considering the existing
   connections, IPv6-only and DS CNs can communicate with the MN using
   native IPv6. As for the communication with IPv4-only CNs, incoming
   packets should go through the translators in the MN's home network
   and then be tunneled to the visited network. Regarding of the
   communications with DS CNs, native IPv6 is used. In summary,
   there is no problem introduced in the handoffs of IPv6-only MNs in
   an IPv6-only or DS network.

4.2 Handoffs of IPv4-only MN

   Table 3. List of handoffs of IPv4-only MN and mechanisms can be
   applied to the communications with CNs.
   --------------------------------------------------------
   From Network To Network      IPv4-only CN    IPv6-only CN
   --------------------------------------------------------
   IPv4-only    IPv4-only       NA4             TR
   IPv4-only    DS              NA4             TR
   DS           IPv4-only       NA4             TR
   DS           DS              NA4             TR
   ---------------------------------------------------------
   TR  : Translator mechanisms such as SIIT and NAT-PT
   NA4 : Native IPv4








<Tsao, Tsirtsis, Boehm>       4

                <draft-ietf-ngtrans-moving-01.txt>         <March, 2002>


   For IPv4-only MN, there are four handoff scenarios. That is, from an
   IPv4-only network to another IPv4-only network, from an IPv4-only
   network to a DS network, from a DS network to an IPv4-only network,
   and from a DS network to another DS network. Table 3 also lists all
   handoff scenarios and mechanisms can be used for the communication
   with CNs. The situations are quite similar as that of IPv6-only MN.
   IPv4-only MN moves to a visited IPv4-only or DS network, and performs
   MIPv4 registration. Regarding of the existing connections, IPv4-only
   CNs can communicate with MN using native IPv4. For the communications
   between MN and IPv6-only CNs, incoming packets have to go to
   translators in the MN's home network first and then be tunneled to
   the visited network. As for DS CNs, native IPv4 is used. In
   summary, there is no new problem introduced in this category.

4.3 Handoffs of DS MNv6

   Table 4. List of handoffs of DS MNv6 and mechanisms can be applied to
   the communications with CNs.
   --------------------------------------------------------------
   From Network To Network      IPv4-only CN            IPv6-only CN
   --------------------------------------------------------------
   IPv6-only    IPv6-only       TR, DSTM                NA6
   IPv6-only    DS              TR, DSTM                NA6
   DS           IPv6-only       TR, DSTM                NA6
   DS           DS              TR, DSTM                NA6
   IPv6-only    IPv4-only       DSTM(v6), NA4(v4)       NA6
   IPv4-only    IPv6-only       DSTM(v6), NA4(v4)       NA6
   IPv4-only    IPv4-only       NA4                     NA6
   IPv4-only    DS              NA4                     NA6
   DS           IPv4-only       NA4                     NA6
   ---------------------------------------------------------------
   TR   : Translator mechanisms such as SIIT and NAT-PT
   NA4  : Native IPv4
   NA6  : Native IPv6
   (v6) : in IPv6-only network
   (v4) : in IPv4-only network

   Table 4 also lists all handoff scenarios and mechanisms can be used
   for the communication with CNs. For a DS MNv6, two sub-categories of
   handoffs are further classified. The first sub-category of handoffs
   includes DS MNv6 moving from an IPv6-only network to another IPv6-
   only network, from an IPv6-only network to a DS network, from a DS
   network to an IPv6-only network, and from a DS network to another DS
   network. This sub-category is very similar to that of IPv6-only MN
   handoffs. DS MNv6 can access IPv6-only and DS networks and perform
   MIPv6 registration. The difference is the communication between DS
   MNv6 and IPv4-only CNs. Since DS MNv6 is dual stack, MN can request
   an IPv4 address via DSTM and send IPv4 packets encapsulated in IPv6
   to IPv4-only CNs through TEP. In this case, translator is no more
   necessary.

<Tsao, Tsirtsis, Boehm>       5

                <draft-ietf-ngtrans-moving-01.txt>         <March, 2002>


   Imagine a DS MNv6 that only performs MIPv6 registration and not
   MIPv4. While stationary and at home the MN does not use its
   MIPv6 capabilities and thus looks like a regular Dual Stack node.
   In an environment like that, one of the most appealing
   interoperability mechanisms proposed by the NGTRANS WG is called
   DSTM[6].

   DSTM allows a dual stack node to use DHCPv6 [8] to configure on
   demand its IPv4 stack. This offers high utilization of IPv4 address
   space and no requirements for IPv4 support in the domain.
   Additionally, while the node has an IPv4 address, it can communicate
   with IPv4-only nodes without the use of Protocol Translators and/or
   Address Translators.

   DSTM has been mainly designed for stationary dual stack nodes. We
   will now examine how a DS MNv6 can take advantage of DSTM in a mobile
   environment. It is clear that if the DS MNv6 is not moving, DSTM can
   be directly applicable i.e., the DS MNv6 can use DHCPv6 over MIPv6 to
   communicate with the DSTM server in the home network and request an
   IPv4 address. The problem is that while MIPv6 can "move" the mobile's
   IPv6 stack between access points in the network, it is not obvious
   how it can move the IPv4 stack of the same DS MNv6.

   [6] assumes that IPv4 routing is not available in the DSTM domain.
   The Dynamic Tunneling Interface (DTI) is defined as an interface that
   encapsulates IPv4 packets into IPv6 packets. The TEP is also defined
   as the destination of the IPv6 packet containing an IPv4 packet.
   Providing the DS MNv6 knows where the TEP is, in the domain it
   happens to be in, it can use MIPv6 to send an encapsulated IPv4
   packet to the IPv4-only CN.

   DS MNv6 essentially uses its MIPv6 COA in the foreign domain to
   request an IPv4 address (and the local TEP) from the local DHCPv6
   server. It then uses IPv6 to communicate with the local TEP and
   encapsulate IPv4 packets destined to external IPv4-only nodes. Even
   if DS MNv6 moves to a new Access Router in this domain, a BU to the
   TEP will allow the IPv6 tunnel and the IPv4 packets it encapsulates
   to be maintained.

   Note that like [9] the level of IPv6 connectivity offered by the
   above combination is very similar to MIPv4 without route optimization
   since the IPv4 address used is in fact a dynamically allocated IPv4
   Home Address. Also like [9], MIPv6 Route optimization is of course
   used for the path between the MN and the TEP in that domain.

   It might also be possible for the MN to use the Home DHCPv6 server
   when in a foreign domain e.g: if the foreign domain does not support
   DHCPv6. This would require DHCPv6 request to be sent through the Home
   Agent of the MN. The reply would then include an IPv4 address and a
   TEP address from the home domain. Data would have to be sent from the
   MN to the HA, then to the TEP and eventually to the CN.



<Tsao, Tsirtsis, Boehm>       6

                <draft-ietf-ngtrans-moving-01.txt>         <March, 2002>


   Second sub-category of handoffs are DS MNv6 moving from an IPv6-only
   network to an IPv4-only network, from an IPv4-only network to an
   IPv6-only network, from an IPv4-only network to another IPv4-only
   network, from an IPv4-only network to a DS network, and from a DS
   network to an IPv4-only network. The problem of this sub-category
   is that a DS MNv6 with an IPv6 address moves to an IPv4-only network
   and can not have MIPv6 support in the visited IPv4-only network.
   The mobile node can still receive IPv6 packets from IPv4-
   only network if IPv4-only network implements 6over4 [10] on the
   boundary routers. However, if IPv4-only network does not implement
   6over4 mechanism, the mobile node cannot receive IPv6 packets. Since
   the mobile node is IPv4/IPv6 dual stack, it receives foreign agent
   advertisement messages from the IPv4 protocol stack. The MN detects
   the movement to an IPv4-only network without 6over4, and then the MN
   can perform the the procedures below.

   First, DS MNv6 asks for a co-located IPv4 COA from the local FA. Once
   it has an IPv4 COA and the IPv4 address of its home agent in IPv6
   home network, it can generate an IPv4-compatible IPv6 address
   and perform the MIPv6 registration. The IPv4 COA can be obtained by
   DHCP or some other dynamic address allocation schemes [4][8]. The
   address allocation issue is out of the scope of this document. To
   support DS MNv6 roaming to IPv4-only networks, MIPv6 home agent MUST
   broadcast its IPv6 and its IPv4 address by home agent advertisement.
   MN MUST keep both IPv6 and IPv4 addresses of its home agent while it
   received the HA advertisement.

   After the MN has these addresses, it sends MIPv6 binding update (BU)
   encapsulated in IPv4 packets to its home agent. Here, we assume that
   home agent is IPv4/IPv6 dual stack. The IPv6 home agent decapsulates
   the MIPv6 BU and updates the new COA of the mobile node.

   Packets to the MN go to the home agent first, and then be tunneled to
   the visited network. The MN thus can receive and decapsulate the
   packets. The procedures are summarized as:

   o In IPv6-only network, IPv6 packets are received and processed by
   IPv6 protocol stack on a mobile node.

   o MN received home agent advertisement with HA's IPv4 and IPv6
   addresses, it keeps both two addresses.

   o The MN, which moves to an IPv4-only network without 6over4 support,
   receives the agent advertisement from MIPv4 foreign agent via the
   IPv4 protocol stack.

   o The mobile node obtains an IPv4 COA by certain mechanisms. It
   generates the IPv4-compatible IPv6 address. MN also has the IPv4
   address of the MIPv6 home agent.






<Tsao, Tsirtsis, Boehm>       7

                <draft-ietf-ngtrans-moving-01.txt>         <March, 2002>


  o The MN sends MIPv6 BU encapsulated in IPv4 packets to its home
   agent. The home agent decapsulates the MIPv6 BU messages and updates
   the COA of the mobile node.

   o Packets to the mobile node go to its home network, and then be
   tunneled to the visited network. Then, packets are encapsulated in
   IPv4 and sent to MN.

   Regarding of DS MNv6 moving back to IPv6-only or DS networks from
   IPv4-only networks, DS MNv6 releases IPv4 COA and registers a new
   IPv6 COA or deregisters with its home agent.

4.4 Handoffs of DS MNv4

   Table 5. List of handoffs of DS MNv4 and mechanisms can be applied to
   the communications with CNs.
   ----------------------------------------------------------------
   From Network To Network      IPv4-only CN    IPv6-only CN
   ----------------------------------------------------------------
   IPv4-only    IPv4-only       NA4             NA6(in), TR(out)
   IPv4-only    DS              NA4             NA6(in), TR(out)
   DS           IPv4-only       NA4             NA6(in), TR(out)
   DS           DS              NA4             NA6
   IPv4-only    IPv6-only       NA4             NA6(in), TR(out)
   IPv6-only    IPv4-only       NA4             NA6(in), TR(out)
   IPv6-only    IPv6-only       NA4             NA6
   IPv6-only    DS              NA4             NA6
   DS           IPv6-only       NA4             NA6
   ----------------------------------------------------------------
   TR    : Translator mechanisms such as SIIT and NAT-PT
   NA4   : Native IPv4
   NA6   : Native IPv6
   (in)  : CN originated
   (out) : MN originated

   Table 5 also lists all handoff scenarios and mechanisms can be used
   for the communication with CNs. For a DS MNv4, two sub-categories of
   handoff are also classified.

   First sub-category includes DS MNv4 moving from an IPv4-only network
   to another IPv4-only network, from an IPv4-only network to a DS
   network, from a DS network to an IPv4- only network, and from a DS
   network to another DS network. This sub-category is very similar to
   that of the IPv4-only MN handoff. DS MNs can access IPv4-only and DS
   networks, and perform MIPv4 registration procedure to its IPv4 home
   agent. The difference is in the communication between MN and IPv6-only
   CNs. Since MN is dual stack, MN can be reached by its IPv4-compatible
   IPv6 address. For the IPv6-only/DS CNs initiates the communication to
   DS MNv4 using IPv4-compatible IPv6 address, no translator is required.




<Tsao, Tsirtsis, Boehm>       8

                <draft-ietf-ngtrans-moving-01.txt>         <March, 2002>


   Second sub-category of handoffs are DS MNv4 moving from an IPv4-only
   network to an IPv6-only network, from an IPv6-only network to an
   IPv4-only network, from an IPv6-only network to another IPv6-only
   network, from an IPv6-only network to a DS network, and from a DS
   network to an IPv6-only network.

   The problem of this sub-category is that a DS MNv4 with an IPv4
   address moves to an IPv6-only network and obtains no MIPv4 messages
   and supports. Since the mobile node is IPv4/IPv6 dual stack, it still
   can receive router advertisement from IPv6 routers and learn that it
   situates in an IPv6-only network. If the IPv6-only network supports
   DSTM [6], the mobile node can ask for a co-located COA, obtain TEP,
   and then send MIPv4 registration request encapsulated in IPv6 packets
   to its home agent. Then, the registration procedure is complete. If
   the IPv6-only network does not support DSTM, the DS MNv4 can perform
   the procedures below.


   The MN detects no DSTM support but receives the IPv6 packets, it
   realizes that it moves to an IPv6-only network. The IPv6 stack
   generates an IPv6 COA by using subnet prefix of the visited network.
   Once the mobile node obtains an IPv6 COA, it resolves an IPv4 address
   by the IPv6 address and also requests the IPv6 address of its IPv4
   home agent. Here, we assume that IPv4 home agent is also IPv4/IPv6
   dual stack. The IPv6 COA and its mapped IPv4 address must be co-
   located addresses allocated by the visited network using any
   mechanism. The mapping between IPv6 and IPv4 addresses can be
   obtained by issuing DNS queries.

   The allocation of the COA in the visited network can be static
   assignment or dynamic allocation. The generation of the IPv6 address
   and the mapping of IPv4 and IPv6 addresses are out of the scope of
   this document. The related information can be found in [4][8].

   Since the home agent is IPv4/IPv6 dual stack, the mobile node has the
   IPv6 address of home agent, the MN can then tunnel MIPv4 registration
   request message to its home agent. Home agent decapsulates the IPv6
   packets, receives the registration message and update MN COA.
   Therefore, packets to the mobile node can be transmitted to the new
   IPv4 COA.

   The procedures for DS MNv4 which moves from an IPv4-only network
   to an IPv6-only network are summarized as:

   o In IPv4-only network, IPv4 packets are received and processed by
   IPv4 protocol stack on a mobile node.

   o The MN, which moves to an IPv6-only network, receives the router
   advertisement from IPv6 router via the IPv6 protocol stack.

   o  The MN requests an IPv4 address and TEP via DSTM. The MN then
   sends MIPv4 registration request to its HA via TEP. Packets to MN
   should go to the home agent first and then be tunneled to the visited
   network.
<Tsao, Tsirtsis, Boehm>       9

                <draft-ietf-ngtrans-moving-01.txt>         <March, 2002>


   o  If DSTM is not supported, MN tries to obtain an IPv6 COA by other
   mechanisms such as autoconfiguration or DHCP in the visited network.
   Then, it resolves an IPv4 address by the IPv6 address, and also
   requests the IPv6 address of its home agent. The mechanisms to obtain
   an IPv6 COA and the mapping between IPv6 and IPv4 addresses are out of
   the scope of the document.

   o The MN sends MIPv4 registration request encapsulated in IPv6
   packets to IPv4 HA. HA updates the COA of the MN.

   o Packets to the MN are first routed to its home network. Home agent
   tunnels the packets to the IPv4 COA.

   Regarding of moving back to IPv4-only or DS networks from IPv6-only
   networks, DS MNv4 releases IPv6 COA and registers a new IPv4 COA or
   deregisters with its home agent.

5. Route optimization

   For some specific handoffs, packet routing between CN and MN can be
   further optimized. Here, we assume that MIPv4 implements route
   optimization.

5.1 DS MNv6 talks to IPv4-only CN

   While DS MNv6 moves to the visited IPv6-only or DS networks with DSTM
   support, DS MNv6 requests an IPv4 address and the local TEP from the
   local DSTM. It can encapsulate IPv4 packets destined to IPv4-only
   CNs in IPv6 packets and sends to the CNs through the local TEP.
   Therefore, DS MNv6 can further send MIPv4 binding update to IPv4-only
   CN. The IPv4-only CN updates its binding caches. After that, the CN
   sends packets to the MN new IPv4 address via the new TEP. Packet
   routing between DS MNv6 and IPv4-only CN is optimized.

   Another situation is that DS MNv6 moves from an IPv6-only network to
   an IPv4-only network while talking to an IPv4-only CN. In this case,
   DS MNv6 uses native IPv4 to talk to CN and sends MIPv4 binding update
   to CN in the visited network. After that, the packets need not go
   through the home TEP anymore.

5.2 DS MNv6 talks to IPv6-only/DS CN

   Considering another scenario that a DS MNv6, talks to an IPv6-only or
   DS CN. The MN changes its point of attachment to an IPv4-only
   network. If the visited network supports 6over4 [3] on the boundary
   routers, the MN can act as a normal IPv6-only MN, and update binding
   information to its home agent and CNs. If the visited network does
   not support 6over4, mechanisms mentioned above present the procedures
   to request an IPv4 COA and register the IPv4-compatible IPv6 address to
   its home agent.




<Tsao, Tsirtsis, Boehm>       10

                <draft-ietf-ngtrans-moving-01.txt>         <March, 2002>


  Regarding of packets from IPv6-only CNs to the MN, they go to the home
  network first, and be tunneled to the MN. To optimize routing, the MN
  can send MIPv6 BU messages to IPv6-only/DS CNs to update their binding
  caches. However, the visited network is IPv4-only, IPv6 packets from DS
  MNv6 can not go to the IPv6-only/DS CNs. To solve this problem, the MN
  can send MIPv6 BU to IPv6-only CNs using reverse tunneling. That is,
  MIPv6 BU is tunneled to its home agent first and then sent to IPv6-only
  CNs. CNs can obtain a tunneling server by tunnel broker mechanisms [12]
  or obtain a pre-configured router [3][11] with dual stack functions, and
  send IPv6 packets to the TEP. The TEP encapsulates the packets into IPv4
  packets and sends to the MN. Therefore, the routing between TEP/MN, and
  TEP/CN are both optimized.

5.3 DS MNv4 talks to IPv4-only CN

   The DS MNv4 might change its point of attachment to an IPv6-only
   network. The DS MNv4 node requests an IPv4 COA by using DSTM[6] or
   the mechanisms presented above. It then can perform MIPv4
   registration to its home agent. For the incoming packets from IPv4-
   only CNs, they go to the home agent first, and then be tunneled to
   the MN. To optimize routing, MN can send MIPv4 BU messages to
   IPv4-only CNs. Since MN is in an IPv6-only network, the MIPv4 BU
   needs to be encapsulated in IPv6 packets to CNs via TEPs. TEP
   decapsulates packets and then forwards the IPv4 packets to IPv4-only
   CNs. Once the IPv4-only CNs get the MIPv4 BU, they send packets to
   the new IPv4 COA address through the new TEP. The routing between
   TEP/MN, and TEP/CN are optimized.

6. Acknowledgments

   The authors would like to thank Jen-Chi Liu(CCL, ITRI), Alan O'Neill
   (Flarion Technologies ) and Scott Corson (Flarion Technologies) for
   their contributions to this memo. We would also like to thank
   Ra Chen(Siemens), Moter Du(Siemens), and YokeJen Lim(Siemens) for
   their many useful comments.

7. References

   [1]  Charles E. Perkins, "IP Mobility Support", IETF
   RFC 2002, Oct. 1996.
   [2]  David B. Johnson and Charles E. Perkins, "Mobility Support in
   IPv6", draft-ietf-mobileip-ipv6-15.txt, July 2001,
   (work in progress).
   [3]  W. Biemolt et al., "A Guide to the Introduction of IPv6 in the
   IPv4 World (TRANSITION)", draft-ietf-ngtrans-introduction-to-ipv6-
   transition-07.txt, July 2001, (work in progress).
   [4]  S. Thomson and T. Narten, "IPv6 Stateless Address
   Autoconfiguration", IETF RFC 2462, Dec. 1998.
   [5]  T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for
   IP Version 6 (IPv6)", IETF RFC 2461, Dec. 1998.
   [6]  Jim Bound et.al, "Dual Stack Transition Mechanism (DSTM)",
   <draft-ietf-ngtrans-dstm-07.txt>, February 2002, (Work in Progress).


<Tsao, Tsirtsis, Boehm>       11

                <draft-ietf-ngtrans-moving-01.txt>         <March, 2002>

   [7]  Carpenter, B., and Jung., C. "Transmission of IPv6 over IPv4
   Domains without Explicit Tunnels", RFC 2529.
   [8]  J. Bound, M. Carney, C. Perkins, and R. Droms.  "Dynamic Host
   Configuration Protocol for IPv6",  draft-ietf-
   dhc-dhcpv6-16.txt, November 2000 (work in progress).
   [9]  H. Soliman, E. Nordmark, "Extensions to SIIT and DSTM for
   enhanced routing of inbound packets", <draft-soliman-siit-dstm-
   01.txt>, November 2001, (Work in Progress).
   [10] B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4 Domains
   without Explicit Tunnels", RFC2529, March 1999.
   [11] R. Gilligan et. al, "Transition Mechanisms for IPv6 Hosts and
   Routers", RFC 2893.
   [12] A. Durand et. al, "IPv6 Tunnel Broker", RFC 3053, January 2001.

Author's Addresses

   Shiao-Li Tsao
   Computer and Communication Research Labs.,
   Industrial Technology Research Institute
   K400 CCL/ITRI Bldg. 51, 195-11 Sec. 4, Chung Hsing Rd., Chutung,
   Hsinchu, Taiwan, 310, R.O.C.
   Tel: +886-3-5914651
   Fax: +886-3-5820310
   E-mail: sltsao@itri.org.tw

   George Tsirtsis
   Flarion Technologies
   Phone: +44-20-88260073
   Email: G.Tsirtsis@Flarion.com

   Wolfgang Boehm
   Siemens Mobile Internet
   Postal Address: Siemens AG, ICM CA MS MI E
   Hofmannstr. 51, 81379 Munich / Germany
   Phone:    +49 89 722 31462
   Fax:        +49 89 722 37661
   e-mail:    wolfgang-j.boehm@icn.siemens.de












   Copyright Notice Placeholder for ISOC copyright.

<Tsao, Tsirtsis, Boehm>       12


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/