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

Versions: 00 01

Network Working Group                                         T. Larsson
Internet-Draft                                             E. Gustafsson
Expires: August 24, 2004                                    H. Levkowetz
                                                                Ericsson
                                                       February 21, 2004


            Use of MIPv6 in IPv4 and MIPv4 in IPv6 networks
                  draft-larsson-v6ops-mip-scenarios-01

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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 August 24, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document considers a heterogeneous network environment with
   interconnected IPv4 (public/private) and IPv6 networks.  The document
   identifies the scenarios relevant for mobility management in such a
   heterogeneous network environment, lists work relevant to deploying
   Mobile IP under these conditions, and gives an inventory of possible



Larsson, et al.          Expires August 24, 2004                [Page 1]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   solutions.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1  Background . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.3  Earlier work . . . . . . . . . . . . . . . . . . . . . . .   4
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.   Problem description  . . . . . . . . . . . . . . . . . . . .   4
   4.   Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.   Related work . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.1  Dual-stack Mobile IPv4-Mobile IPv6 . . . . . . . . . . . .   9
     5.2  Enhanced Mobile IPv4 . . . . . . . . . . . . . . . . . . .  10
     5.3  Enhanced Mobile IPv6 . . . . . . . . . . . . . . . . . . .  11
     5.4  ISATAP . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     5.5  Teredo . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     5.6  STEP . . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     5.7  6to4 . . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     5.8  Doors  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     5.9  TSP  . . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   6.   Possible Solutions . . . . . . . . . . . . . . . . . . . . .  14
     6.1  Dual-stack MIPv4-MIPv6 . . . . . . . . . . . . . . . . . .  15
     6.2  Enhanced MIPv4 . . . . . . . . . . . . . . . . . . . . . .  15
     6.3  Enhanced MIPv6 . . . . . . . . . . . . . . . . . . . . . .  16
     6.4  MIPv6 with ISATAP  . . . . . . . . . . . . . . . . . . . .  16
     6.5  MIPv6 with Teredo and 6to4 . . . . . . . . . . . . . . . .  17
     6.6  MIPv6 with STEP  . . . . . . . . . . . . . . . . . . . . .  18
     6.7  MIPv6 or MIPv4 with TSP  . . . . . . . . . . . . . . . . .  18
   7.   Conclusions  . . . . . . . . . . . . . . . . . . . . . . . .  19
   8.   Security Considerations  . . . . . . . . . . . . . . . . . .  21
   9.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  21
   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  21
     10.1   Normative References . . . . . . . . . . . . . . . . . .  21
     10.2   Informative References . . . . . . . . . . . . . . . . .  22
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  24
   A.   Supported scenarios per solution . . . . . . . . . . . . . .  25
   B.   Transport overhead per solution  . . . . . . . . . . . . . .  26
   C.   Registration message roundtrips per solution . . . . . . . .  27
        Intellectual Property and Copyright Statements . . . . . . .  29











Larsson, et al.          Expires August 24, 2004                [Page 2]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


1.  Introduction

1.1  Background

   The Mobile IPv4 [RFC3344] protocol was designed for mobility
   management in pure IPv4 networks.  Similarly, Mobile IPv6 [RFC3775]
   has been designed for mobility management in pure IPv6 networks.  As
   IPv6 is introduced, it will most likely be through stepwise
   deployment, resulting in a heterogeneous network environment with
   interconnected IPv4 and IPv6 networks, where the IPv4 networks can be
   either of public or private address realm.  It is probable that this
   type of network environment will be common for a long period of time.

   A heterogeneous network environment, as described above, requires a
   solution for mobility management that runs over both IPv4 and IPv6
   networks, including support for public as well as private IPv4
   address spaces.  This means that the mobility management solution
   needs to be able to cope with the Network Address Translators (NATs)
   [RFC2663] and Network Address Port Translators (NAPTs) [RFC2663] that
   are already deployed between public and private IPv4 address spaces.
   The term NAT refers to both NATs and NAPTs in the remainder of this
   document.

   Mobile IPv4 defines a mechanism which enables nodes to change their
   point of attachment to the Internet without changing their IP
   address, i.e.  IPv4 home address.  Mobile IPv6 defines a similar
   mechanism for IPv6 networks.  A solution for mobility management in a
   heterogeneous network environment should make it possible for nodes
   to change their point of attachment to the Internet without changing
   their IPv4 and IPv6 addresses, i.e.  IPv4 home address and IPv6 home
   address.  This will make it possible for the mobile nodes to maintain
   seamless connectivity for both their IPv4 and IPv6 applications.

1.2  Scope

   The scope of this document is to identify the network and handoff
   scenarios relevant for mobility management in combined IPv4 (public/
   private) and IPv6 networks.  We also provide an overview of related
   work that has been published earlier.  Lastly, we list possible
   solutions, compliant to Mobile IP, and summarize their properties and
   applicability to the network and handoff scenarios.

   The purpose of this document is explicitly not to describe any
   particular problem that has to be solved within this area.  A problem
   statement needs to express many parameters related to the
   characteristics of access technology (cellular, 802.3, 802.11,
   802.16, 802.20 etc.), predominant traffic (VoIP, Browsing, Terminal
   access, multimedia streams, ...), reachability requirements (global



Larsson, et al.          Expires August 24, 2004                [Page 3]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   or intra-network only reachability) and conceivably other.
   Individual problem statements are needed to lay out these parameters
   - this document seeks to define the field of combinations of the base
   IP and MIP technologies which should be considered when looking at
   possible solutions to individual problem statements.

   Dynamic assignment of address in the home network, i.e., dynamic
   Mobile IP Home Address assignment is not covered here.  If such
   assignments are done dynamically, they still happen only at the time
   of initial registration, not at every handoff.  They therefore do not
   affect handoff characteristics, and also do not affect tunnel
   overhead, and thus are out of scope for this document.

   Network attachment is also out of scope for this document.  It is
   assumed that in any combination of the conceivable solutions
   discussed below, it is first necessary to determine whether one is
   attached to a new network or to one where connectivity has already
   been established.  In a new network it is then, for all discussed
   solutions, necessary to obtain an address in the visited network, and
   the details of that operation would not affect the tunneling overhead
   or choice of tunneling technology.  We somewhat arbitrarily choose to
   ignore the one case which is slightly different in this respect - the
   case where a MIPv4 FA (Foreign Agent) is present in the visited
   network.  In this case, the task of obtaining a local address is
   unnecessary, but it is still necessary for the Mobile Node to
   determine that there is an FA present.

1.3  Earlier work

   The issue has in parts been described earlier in [I-D.ietf-ngtrans-
   moving], [I-D.tsao-mobileip-dualstack-model], [I-D.tsirtsis-dsmip-
   problem], [I-D.soliman-v4v6-mipv4] and [I-D.tsirtsis-v4v6-mipv4].
   None of these drafts, however, provides an exhaustive list of
   scenarios for mobility in combined IPv4 (public/private) and IPv6
   networks.

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
   levels for compliant implementations.

3.  Problem description

   This draft outlines scenarios for mobility management in
   heterogeneous network environments, i.e. including public and private



Larsson, et al.          Expires August 24, 2004                [Page 4]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   IPv4 address spaces, IPv6 address spaces as well as NATs and NAPTs.

   Although there is currently no standardized Mobile IP-based solution
   that handles all the different aspects of this type of network
   scenario, a number of solutions for Mobile IP across heterogeneous
   networks have been proposed.  This draft outlines possible solutions,
   and comments on what types of network scenarios they apply to.

   To be able to analyze solutions for Mobile IP mobility over
   heterogeneous networks, we have estimated parameters such as
   transport overhead (e.g. tunneling), handoff latency (e.g. number of
   signaling roundtrips between the mobile node and its home network),
   and signaling overhead (e.g. tunneling of registration messages, or
   keep-alive messages) for the different solutions.  These parameters,
   in combination with deployment issues and impact on existing infra-
   structure, assumed or imposed by the different solutions, give an
   overview of the their suitability in different deployment scenarios.

   The issue of handoff latency would be especially important in cases
   where Mobile IP provides mobility for real-time applications, e.g.
   Voice over IP calls.  In these cases, an absolute minimum of
   signaling roundtrips is required at each handoff.  Also, when running
   real-time applications, a mobile node cannot afford to await timeouts
   in deciding which mobility signaling mechanism to use when arriving
   at a new access network.

   Overhead, for transport or signaling, may be significant in the case
   of wireless access networks, where traffic over the air needs to be
   kept at a minimum.  Furthermore, requirements on introducing
   additional authentication mechanisms and systems for subscription/
   user management are also a key factor in evaluating different
   solutions.

   This draft does not consider performance in terms of mechanisms for
   movement detection.

   A summary of the proposed solutions and a discussion about their
   properties is provided in the conclusions section.

4.  Scenarios

   This section describes relevant network scenarios for mobility in
   IPv4 (public/private) and IPv6 networks.  We also outline deployment
   cases and discuss which network scenarios that need to be fulfilled
   for a solution to fully support mobility over heterogeneous access
   networks.

   In the tables below, "MN" refers to the IP version run on the MN



Larsson, et al.          Expires August 24, 2004                [Page 5]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   (requested by application), "MIP" refers to the Mobile IP version run
   on the MN and on the HA, "Access" reflects the IP version run on the
   access network (visited or home), and "Transport" refers to the
   transport network between the visited and the home network.

   The scenarios are based on the following general assumptions:
   o  The MN supports and runs Mobile IP; either MIPv4 or MIPv6.
   o  The MN is associated with a HA supporting the same Mobile IP
      version as the MN.
   o  If the access network runs IPv4, there may or may not be FA
      support.  A Mobile IPv4-compliant solution should be able to
      handle both cases.
   o  If the MN, HA and CN run MIPv6, a MIPv6-compliant solution should
      support route optimization between the MN and the CN.
      Alternatively, the MN should know precisely under what conditions
      to use route optimization and when to use reverse tunneling.

   Scenarios including Network Address Translation - Protocol
   Translation (NAT-PT) [RFC2766] nodes, which will be found on the
   boundaries between IPv6 networks and IPv4 networks, are not included
   in this document.  The use of NAT-PT has been analyzed in several
   other documents ([I-D.satapati-v6ops-natpt-applicability], [I-D.ietf-
   v6ops-3gpp-analysis]) where the use of NAT-PT as a general-purpose
   transition mechanism is discouraged.  NAT-PT should only be viewed as
   a short-term solution in specific deployment scenarios.

   Table 1: Network scenarios without NAT/NAPT between the access
   network and the transport network.

     ----------------------------------------------------------------
     #   MN     MIP    Access  Transport    Description
     ----------------------------------------------------------------
     1   IPv4   MIPv4   IPv4     IPv4       "Native MIPv4"
     2   IPv6   MIPv4   IPv4     IPv4       "IPv6 in MIPv4"
     3   IPv4   MIPv6   IPv4     IPv4       "IPv4 in MIPv6 over IPv4"
     4   IPv6   MIPv6   IPv4     IPv4       "MIPv6 over IPv4"
     5   IPv4   MIPv4   IPv6     IPv6       "MIPv4 over IPv6"
     6   IPv6   MIPv4   IPv6     IPv6       "IPv6 in MIPv4 over IPv6"
     7   IPv4   MIPv6   IPv6     IPv6       "IPv4 in MIPv6"
     8   IPv6   MIPv6   IPv6     IPv6       "Native MIPv6"
     ----------------------------------------------------------------










Larsson, et al.          Expires August 24, 2004                [Page 6]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   Table 2: Network scenarios with NAT/NAPT between the access network
   and the transport network.

     ------------------------------------------------------------------
     #   MN     MIP     Access    Transport   Description
     ------------------------------------------------------------------
     9   IPv4   MIPv4   IPv4-priv   IPv4      "Native MIPv4"
     10  IPv6   MIPv4   IPv4-priv   IPv4      "IPv6 in MIPv4"
     11  IPv4   MIPv6   IPv4-priv   IPv4      "IPv4 in MIPv6 over IPv4"
     12  IPv6   MIPv6   IPv4-priv   IPv4      "MIPv6 over IPv4"
     ------------------------------------------------------------------

   Based on the network scenarios in Table 1 and 2, we can derive
   different handoff scenarios, i.e. as the mobile node moves between
   access networks supporting different IP versions.  Table 3 describes
   the handoff scenarios generated from the network scenarios in Table
   1.  The column "Access handoff" describes bi-directional handoff
   scenarios, e.g.  "IPv4-IPv6" refers to handoffs from an IPv4 to an
   IPv6 access network, as well as from an IPv6 to an IPv4 access
   network.

   Table 3: Handoff scenarios generated from Table 1.

     -------------------------------------------------------------
     #   MN     MIP    Access handoff      Description
     -------------------------------------------------------------
     a   IPv4   MIPv4    IPv4-IPv4       "Native MIPv4"
     b   IPv6   MIPv4    IPv4-IPv4       "IPv6 in MIPv4"
     c   IPv4   MIPv4    IPv4-IPv6       "MIPv4 over IPv6"
     d   IPv6   MIPv4    IPv4-IPv6       "IPv6 in MIPv4 over IPv6"
     e   IPv4   MIPv4    IPv4-IPv6       "MIPv4 over IPv6"
     f   IPv6   MIPv4    IPv4-IPv6       "IPv6 in MIPv4 over IPv6"
     g   IPv4   MIPv4    IPv6-IPv6       "MIPv4 over IPv6"
     h   IPv6   MIPv4    IPv6-IPv6       "IPv6 in MIPv4 over IPv6"
     i   IPv4   MIPv6    IPv4-IPv4       "IPv4 in MIPv6 over IPv4"
     j   IPv6   MIPv6    IPv4-IPv4       "MIPv6 over IPv4"
     k   IPv4   MIPv6    IPv4-IPv6       "IPv4 in MIPv6 over IPv4"
     l   IPv6   MIPv6    IPv4-IPv6       "MIPv6 over IPv4"
     m   IPv4   MIPv6    IPv4-IPv6       "IPv4 in MIPv6 over IPv4"
     n   IPv6   MIPv6    IPv4-IPv6       "MIPv6 over IPv4"
     o   IPv4   MIPv6    IPv6-IPv6       "IPv4 in MIPv6"
     p   IPv6   MIPv6    IPv6-IPv6       "Native MIPv6"
     -------------------------------------------------------------

   Table 4 complements Table 3 by describing handoff cases generated
   from Tables 1 and 2, i.e. between IPv6 and public/private IPv4
   address spaces.




Larsson, et al.          Expires August 24, 2004                [Page 7]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   Table 4: Handoff scenarios to/from private IPv4, generated from Table
   1 and 2.

     ----------------------------------------------------------------
     #   MN     MIP    Access handoff         Description
     ----------------------------------------------------------------
     aa  IPv4   MIPv4  IPv4 - IPv4-priv     "Native MIPv4"
     bb  IPv6   MIPv4  IPv4 - IPv4-priv     "IPv6 in MIPv4"
     cc  IPv4   MIPv4  IPv6 - IPv4-priv     "MIPv4 over IPv6"
     dd  IPv6   MIPv4  IPv6 - IPv4-priv     "IPv6 in MIPv4 over IPv6"
     ee  IPv4   MIPv4  IPv6 - IPv4-priv     "MIPv4 over IPv6"
     ff  IPv6   MIPv4  IPv6 - IPv4-priv     "IPv6 in MIPv4 over IPv6"
     gg  IPv4   MIPv6  IPv4 - IPv4-priv     "IPv4 in MIPv6 over IPv4"
     hh  IPv6   MIPv6  IPv4 - IPv4-priv     "MIPv6 over IPv4"
     ii  IPv4   MIPv6  IPv6 - IPv4-priv     "IPv4 in MIPv6 over IPv4"
     jj  IPv6   MIPv6  IPv6 - IPv4-priv     "MIPv6 over IPv4"
     kk  IPv4   MIPv6  IPv6 - IPv4-priv     "IPv4 in MIPv6 over IPv4"
     ll  IPv6   MIPv6  IPv6 - IPv4-priv     "MIPv6 over IPv4"
     ----------------------------------------------------------------

   Regarding deployment of Mobile IP, we identify three main cases:
   o  Case I (MIPv4-based): Mobile IPv4 is already deployed in an
      operator's/ISP's networks, and a solution is needed to allow
      Mobile IPv4 to work over both IPv4 and IPv6 address spaces.
   o  Case II (MIPv6-based): Mobile IPv4 is not deployed, but the
      operator/ISP plans to deploy Mobile IPv6 directly, and needs a
      solution to allow Mobile IPv6 to work over both IPv4 and IPv6
      networks.
   o  Case III (MIPv4-MIPv6): Mobile IPv4 is deployed by an operator/ISP
      who now plans to migrate to Mobile IPv6, and therefore needs a
      solution for Mobile IPv4-Mobile IPv6 migration.

   These deployment cases are reflected in solutions proposed for
   mobility over IPv4/IPv6 networks.

   For a mobility solution to fulfill the requirement of supporting
   "heterogeneous access networks", it should support both IPv4 and IPv6
   applications running continuously on the mobile node, while the
   mobile node moves between IPv6 and IPv4 (public and private) access
   networks.  In essence, this means that the mobile node must be able
   to communicate with its home agent over both IPv4 and IPv6 networks,
   and that the Mobile IP stack in the mobile node (MIPv4 or MIPv6) must
   provide Mobile IP transport for both IPv4 and IPv6 sockets.

   This can be provided in any of the three deployment scenarios
   described above:





Larsson, et al.          Expires August 24, 2004                [Page 8]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   o  A solution for deployment case I (MIPv4-based) needs to handle
      network scenarios 1-2, 5-6 in Table 1 and 9-10 in Table 2, as well
      as handoff scenarios a-h in Table 3 and aa-ff in Table 4.
   o  A solution for deployment case II (MIPv6-based) needs to handle
      network scenarios 3-4, 7-8 in Table 1 and 11-12 in Table 2, as
      well as handoff scenarios i-p in Table 3 and gg-ll in Table 4.
   o  A solution for deployment case III (MIPv4-MIPv6) needs to handle
      network scenarios 1-2, 7-8 in Table 1 and 9-10 in Table 2.  The
      handoff scenarios listed in Tables 3 and 4 are not really
      applicable to this type of solution.  As the aim is to address
      MIPv4-MIPv6 interworking, we may assume that MIPv4 and MIPv6 run
      in parallel on the MN and the HA, and that the MN will be able to
      shift MIP version during a handoff, accommodating to the IP
      version of its current access network.  For this to work, the MIP
      stack in the MN also needs to provide the appropriate MIP
      transport for both IPv4 and IPv6 sockets.

   Solutions for Mobile IP mobility management over IPv4/IPv6 networks
   can be roughly divided into two main categories: (a) solutions
   defining extensions to the Mobile IP standards (MIPv4/MIPv6), and (b)
   solutions based on existing Mobile IP standards combined with
   existing transition mechanisms.  When relying on existing transition
   mechanisms, we add to the network scenarios in Tables 1 and 2 by
   allowing the transport network to have a different IP version than
   the access network.  The transition mechanism is assumed to handle
   for instance a scenario with a Mobile IPv6 mobile node, an IPv4
   access network and an IPv6 transport network.  While a transition
   mechanism would allow native Mobile IPv6 signaling over an IPv4
   access network, extensions to the mobility protocol would still be
   needed for e.g. the Mobile IPv6 host to provide Mobile IPv6 transport
   for IPv4 payload.

   Related work and possible solutions are discussed in the following
   sections.

5.  Related work

   The following lists related work, explains how it relates to the
   different deployment cases, and reflects upon its applicability to
   Mobile IP-based mobility management over heterogeneous address
   spaces.  Different solutions are further evaluated in coming sections
   and in the appendixes.

5.1  Dual-stack Mobile IPv4-Mobile IPv6

   Implementing dual-stack (DS) nodes with support for standard Mobile
   IPv4 and Mobile IPv6 is described in [I-D.tsao-mobileip-dualstack-
   model].  This implementation includes an address mapper, located



Larsson, et al.          Expires August 24, 2004                [Page 9]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   between the IP layer and the Mobile IP layer, which can associate a
   home address of one IP version with a care-of address of another IP
   version.  By dispatching IPv4/IPv6 packets to the correct layers, the
   address mapper provides a transparent service to upper layer
   protocols.

   The dual-stack MIPv4-MIPv6 solution addresses the network scenario
   cases 1-8 in Table 1, and cases 9, 10 in Table 2.  This solution also
   addresses handoff between IPv4 and IPv6 access networks.

   The dual-stack MIPv4-MIPv6 solution supports deployment case III, of
   co-existing Mobile IPv4 and Mobile IPv6.  However, drawbacks of this
   solution, also pointed out in [I-D.tsirtsis-dsmip-problem], are that
   the mobile node and home agent both need to support two sets of
   mobility protocols, that the mobile node needs to send two sets of
   signalling messages at each handoff, and that network administrators
   need to run and maintain two sets of mobility management systems,
   including subscription management, on the same network.

5.2  Enhanced Mobile IPv4

   Extending Mobile IPv4 to support IPv6 address spaces supports
   deployment case I, i.e. where an operator/ISP already has Mobile IPv4
   running, and aims to support IPv6 address spaces by enhancing Mobile
   IPv4.  This type of solution addresses network scenario cases 1-2,
   5-6 in Table 1, and cases 9-10 in Table 2.  It also addresses handoff
   cases a-h in Table 3 and handoff cases aa-ff in Table 4.  That is,
   cases with descriptions "Native MIPv4", "IPv6 in MIPv4", "MIPv4 over
   IPv6" and combinations of these.

   A solution of this kind consists of two parts:
   1.  Enhance MIPv4 to provide support for tunneling MIPv4 packets over
       IPv6 transports.  This solves scenario 5 in addition to 1, and
       scenario 6 if combined with the enhancement below.  We denote
       such a solution "MIPv4o".
   2.  Enhance MIPv4 to carry IPv6 payloads.  This solves scenario 2,
       and scenario 6 if combined with the enhancement above.  We denote
       such a solution "MIPv4x".
   MIPv4 enhanced in both respect we will denote "MIPv4xo".

   A solution to part 1 above is proposed in [I-D.tsirtsis-v4v6-mipv4].
   This solution assumes dual-stack nodes with Mobile IPv4 support (HA,
   MN, FA), and defines extensions to Mobile IPv4 to support IPv6 home
   address and IPv6 care-of address for the mobile node.  Relying on
   today's standard Mobile IPv4, this solution supports both public and
   private IPv4 address spaces, and supports scenario cases 1, 5 and 9.





Larsson, et al.          Expires August 24, 2004               [Page 10]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


5.3  Enhanced Mobile IPv6

   Extending Mobile IPv6 to support IPv4 address spaces supports
   deployment case II, i.e. where an operator/ISP deploys Mobile IPv6
   without having deployed Mobile IPv4, and thus seeks to support IPv4
   address spaces by enhancing Mobile IPv6.

   This type of solution addresses network scenario cases 3-4, 7-8 in
   Table 1, and handoff cases i-p in Table 3.  In summary, cases with
   descriptions "Native MIPv6", "IPv4 in MIPv6", "MIPv6 over IPv4" and
   combinations of these.

   A solution of this kind consists of two parts:
   1.  Enhance MIPv6 to provide support for tunneling MIPv6 packets over
       IPv4 transports.  This solves scenario 4 in addition to 8, and
       scenario 3 if combined with the enhancement below.  We denote
       such a solution "MIPv6o".
   2.  Enhance MIPv6 to carry IPv4 payloads.  This solves scenario 7,
       and scenario 3 if combined with the enhancement above.  We denote
       such a solution "MIPv6x".
   MIPv6 enhanced in both respect we will denote "MIPv6xo".

   The draft [I-D.soliman-v4v6-mipv4] proposes an enhanced Mobile IPv6
   solution to the first part above, for public IPv4 address spaces
   only.  This solution assumes dual-stack nodes (HA, MN), and extends
   Mobile IPv6 so that the MN can simultaneously maintain connections to
   its IPv4 and IPv6 home address respectively.

   If this solution was further enhanced to support private IPv4 address
   spaces, it would also support network scenario case 12 in Table 2,
   and handoff cases hh, jj and ll in Table 4.  This would, however,
   generate additional overhead.

5.4  ISATAP

   ISATAP [I-D.ietf-ngtrans-isatap] specifies a protocol connecting IPv6
   hosts and routers within IPv4 sites.  ISATAP allows dual-stack nodes
   that do not share a link with an IPv6 router to automatically tunnel
   packets to the IPv6 next-hop address through IPv4, i.e. the site's
   IPv4 infrastructure is treated as a link layer for IPv6.  ISATAP
   enables automatic IPv6-in-IPv4 tunneling for both public and private
   IPv4 addresses.  Use of private IPv4 addresses will, however, require
   that no NAT(s) exist between the host and the ISATAP router.  A NAT
   can be deployed in parallel with the ISATAP router if the ISATAP
   router provides global IPv4 connectivity in parallel with IPv6
   connectivity.

   In combination with Mobile IPv6 [RFC3775], ISATAP can provide



Larsson, et al.          Expires August 24, 2004               [Page 11]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   mobility support for deployment case II (MIPv6-based).

5.5  Teredo

   The Teredo solution [I-D.huitema-v6ops-teredo] addresses the generic
   issue of providing IPv6 service to nodes located behind one or
   several IPv4 NATs.  The mechanism for achieving this is tunneling of
   IPv6 over UDP through the NATs.  The key components of the Teredo
   service are: (i) Teredo client - a node that has IPv4 and needs IPv6
   connectivity; (ii) Teredo server - provides IPv6 connectivity to
   Teredo clients; (iii) Teredo relay - IPv6 router forwarding traffic
   to Teredo clients; and (iv) Teredo IPv6 address - IPv6 address
   consisting of the specific Teredo prefix, Teredo server IPv4 address,
   client IPv4 address, client UDP port number and a flag indicating
   type of NAT.  (Teredo provides connectivity through the most usual
   types of NATs, and for those for which full connectivity is not
   possible, workarounds may be devised which sacrifice MIPv6 route
   optimization.)

   The normal operation mode of Teredo involves three actors: Teredo
   client needing IPv6 connectivity behind a NAT, Teredo servers
   providing the service, and Teredo relays providing for the
   interconnection between the Teredo service and the native IPv6
   Internet.  The relays are connected to the IPv6 Internet and
   participate in IPv6 routing.  They announce the Teredo IPv6 prefix
   and are able to relay IPv6 packets over IPv4 UDP towards the client.
   Teredo servers enable NAT traversal and are designed so that when NAT
   traversal is guaranteed, packets flow on a direct path between source
   and destination.  It should be noted, however, that Teredo's default
   mode of operation requires changes in the IPv6 routers, e.g.  Teredo
   relays.

   Another possibility is to deploy Teredo as a stateful tunnel server
   instead of the default mode where it is stateless.  The Teredo server
   will then act as a tunnel broker, i.e. the Teredo server will be the
   end-point of the tunnel and all traffic needs to be tunneled through
   it.  This eliminates the need for relays and makes Teredo useful in
   supporting IP mobility, e.g. in combination with Mobile IPv6
   [RFC3775] and enhanced MIPv6 as discussed above [I-D.soliman-v4v6-
   mipv4].

5.6  STEP

   The STEP draft [I-D.savola-v6ops-conftun-setup] describes mechanisms
   to establish IPv6-in-IPv4 tunnels between an ISP and its customer.
   During the STEP procedure, the customer discovers (using one of many
   possible methods) the IPv4 tunnel end-point of the ISP, and a tunnel
   is then established between the customer and the ISP.  STEP addresses



Larsson, et al.          Expires August 24, 2004               [Page 12]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   NAT traversal through use of either protocol 41 (IPv6 over IPv4
   tunnels) or UDP encapsulation.

   One of the main ideas behind STEP is to provide this tunnel service
   without additional protocol specification or substantial
   modifications to IPv6 or IPv4 implementations either at the ISP or
   customer side, i.e. existing mechanisms for e.g. prefix delegation
   and authentication are used.

   In combination with Mobile IPv6, STEP can provide mobility support
   for deployment case II (MIPv6-based).

5.7  6to4

   The draft [I-D.kahng-mobileip-moving6to4] proposes a solution based
   on 6to4 for MIPv6 mobility management over IPv6 transition networks
   (IPv6 sites interconnected over an IPv4 wide area network).  The main
   focus of this draft is selection of home address and care-of address
   when both IPv6 and 6to4 addresses are available.

   This solution primarily addresses cases where the mobile node has
   IPv6 connectivity to a correspondent node, and where either the
   mobile node, the correspondent node, or both move between IPv6 and
   6to4 access networks.  Although the draft does not mention native
   IPv4 access networks, this scenario may also be supported through
   implementation of the 6to4 router in the mobile node itself.  For
   such a solution to work, the home network needs 6to4 functionality in
   order to receive packets from the mobile node.  The same applies to
   the correspondent node (or its access network), in case route
   optimization is used.  Also, the solution would in most cases not
   support NAT traversal between the mobile node and its home agent, or
   between the mobile node and the correspondent node.  I.e., only
   traversal of NATs allowing IPv6-in-IPv4 tunnels through would be
   supported.  It should be noted, however, that the 6to4 solution
   [RFC3056] states that the 6to4 mechanism is almost entirely
   implemented in border routers, rather than hosts.

   In itself, this solution addresses only in part deployment case II.
   However, combined with, e.g.  Teredo, it addresses deployment case II
   in its entirety, including NAT traversal.

5.8  Doors

   Another way of using the 6to4 mechanism to support Mobile IPv6 over
   IPv4 is named Doors [I-D.thubert-nemo-ipv4-traversal].  The proposed
   Doors mechanism adds some features, notably NAT traversal, to that
   provided by using base 6to4, but the description does not go into
   sufficient detail that it was judged necessary (at the level of this



Larsson, et al.          Expires August 24, 2004               [Page 13]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   document) to do a separate analysis of Doors, as distinct from base
   6to4 [RFC3056].

5.9  TSP

   The Tunnel Setup Protocol (TSP) [I-D.blanchet-v6ops-tunnelbroker-tsp]
   is a protocol to set up tunnels between a client and a tunnel server,
   possibly through a broker.  This protocol, which uses XML messaging
   and SASL authentication, can negotiate the setup of, e.g.  IPv6-in-
   IPv4, IPv6-in-UDP-in-IPv4 or IPv4-in-IPv6 tunnels.

   To set up a tunnel, once the client has located a server or broker,
   it sends the current protocol version it supports, and the server
   replies with a list of capabilities supported for authentication and
   tunnels.  The client then authenticates itself to the server and,
   upon successful authentication, requests a tunnel setup to the
   server.

   Provided that TSP is deployed, it could be used to set up IPv6-in-
   IPv4 or IPv6-in-UDP-in-IPv4 tunnels that would allow MIPv6 mobile
   nodes connectivity over IPv4 networks.  In this case, TSP would
   address deployment case II (MIPv6-based).  If used to set up IPv4-in-
   IPv6 tunnels, TSP would also address deployment case I (MIP4-based).

6.  Possible Solutions

   This section describes and evaluates different combinations of the
   solutions discussed in the previous section, including how these
   combinations apply to the different deployment cases.  Rough
   performance estimations, in terms of added transport overhead and
   roundtrips for handoff signaling, are also listed - below and in the
   appendixes.

   As mentioned earlier, there are roughly two categories of solutions:
   based on extensions to the Mobile IP protocols, or based on existing
   transition mechanisms.  There are three solutions extending the
   Mobile IP protocols: "Dual-stack MIPv4-MIPv6", "Enhanced MIPv4" and
   "Enhanced MIPv6".  As for solutions relying on existing transition
   mechanisms, we identify the following: "MIPv6 with ISATAP", "MIPv6
   with Teredo and 6to4", "MIPv6 with STEP", and "MIPv6 or MIPv4 with
   TSP".

   In general, transition mechanisms solve the issue of transporting,
   e.g.  MIPv6 over an IPv4 network (public or private).  Mechanisms in
   the host for allowing the Mobility protocol to transport multiple IP
   protocol versions, rather than only the native IP protocol version,
   need to be addressed through extensions to the Mobility protocol
   (MIPv4x/MIPv6x).



Larsson, et al.          Expires August 24, 2004               [Page 14]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


6.1  Dual-stack MIPv4-MIPv6

   The DS MIPv4-MIPv6 solution [I-D.tsao-mobileip-dualstack-model],
   addresses deployment case III, of co-existing MIPv4 and MIPv6.
   Through its implementation of dual stacks as well as dual  MIP
   protocols, this solution generates overhead, compared to native MIPv4
   or MIPv6.

   First, the MN needs to implement MIPv4, MIPv6 and an address mapper.
   The HA also needs to implement both MIPv4 and MIPv6.  This includes
   implementation of double sets of security bindings, subscription
   management etc.

   Second, double sets of registration/binding update signaling
   messages, MIPv4 and MIPv6, are generated at each handoff.  This
   results in a total of four signaling messages for each handoff,
   equaling to two signaling roundtrips between the MN and the HA.  The
   signaling messages for MIPv4 and MIPv6 are, however, sent in
   parallel.  Therefore, the latency for handoff signaling should
   correspond to one roundtrip rather than two.  The overhead though,
   counted in number of signaling messages, is twice as much as for
   stand-alone MIPv4 or MIPv6 signaling.  Also, there is additional
   overhead due to tunneling of registration messages; either MIPv4
   registration in IPv6, or MIPv6 binding update in IPv4.  As for
   transport overhead, this solution compares to native MIPv4 or MIPv6.

6.2  Enhanced MIPv4

   Enhanced MIPv4 addresses deployment case I by extending native MIPv4
   to support both IPv4 and IPv6 home addresses at the same time.
   Enhanced MIPv4 affects the MN and the HA, as both the MN and the HA
   need to be configured with each other's IPv4 and IPv6 addresses.

   The number of signaling messages at a handoff is the same as for
   native MIPv4 - registration request and reply, generating a total of
   one signaling roundtrip.  This solution also adds a few extensions to
   the registration request/reply messages: a skippable IPv6 home
   address extension of 20 bytes, and a skippable IPv6 compatibility
   extension of 4 bytes, in order to transport MIPv4 over IPv6 (MIPv4o).
   Another extension of length 4 bytes is needed to arrange for carrying
   IPv6 payloads in MIPv4 (MIPv4x).  Also, in case of an IPv6 access
   network, the registration signaling is tunneled in IPv6, generating
   an extra 40 bytes overhead (IPv6 header).

   As for the transport overhead, Enhanced MIPv4 generates an additional
   40 bytes (IPv6 header) due to tunneling over IPv6 networks.





Larsson, et al.          Expires August 24, 2004               [Page 15]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


6.3  Enhanced MIPv6

   Enhanced MIPv6 addresses deployment case II by extending native MIPv6
   to support both a (public) IPv4 and IPv6 home address simultaneously
   (MIPv6o).  Introducing enhanced MIPv6 affects the MN and the HA.  The
   MN must, in addition to the Mobile IPv6 configuration, be configured
   with the IPv4 address of the home agent, and must possibly also be
   configured with an IPv4 home address.  (The IPv4 home address can be
   dynamically requested as well.)  The HA needs to store the MN's IPv4
   and IPv6 home addresses, as well as the current care-of-address(es).
   This means two entries in the binding update list of the HA; one for
   the IPv6 home address and one for the IPv4 home address.

   The number of signaling messages at each handoff is the same as for
   Mobile IPv6.  This means a total of two signaling messages, e.g. one
   binding update and one binding acknowledgement at each handoff,
   resulting in one signaling roundtrip.  The signaling overhead is
   somewhat larger compared to Mobile IPv6, i.e. the binding update is
   extended with 6 bytes (IPv4 home address option) and the binding
   acknowledgement is extended with 8 bytes (IPv4 address
   acknowledgement option).  In order to arrange to carry IPv4 in MIPv6
   (MIPv6x, scenarios 3 and 7), a further extension of length 4 bytes is
   needed.  Additional tunneling overhead for signaling will also be
   generated in IPv4 access networks due to the fact that the MIPv6
   binding updates must be encapsulated in IPv4, i.e. 20 bytes.

   As for transport overhead, in IPv4 access networks the traffic is
   tunneled IPv6-in-IPv4, thus adding an extra 20 bytes (IPv4 header)
   compared to native MIPv6.

   It should be noted that this solution does not support route
   optimization when the mobile node is located in an IPv4 access
   network.

   As mentioned earlier, the Enhanced Mobile IPv6 solution could be
   further enhanced to support private IPv4 address spaces, i.e. to
   support NAT traversal.  By doing so, the solution would support
   deployment case II in its entirety, at the cost of additional
   overhead.

6.4  MIPv6 with ISATAP

   As mentioned earlier, ISATAP in combination with Mobile IPv6
   [RFC3775] provides mobility support for deployment case II.
   Deployment-wise, this solution assumes an ISATAP router with IPv6
   connectivity in the access network, and an ISATAP client in the MN.
   This solution allows Mobile IPv6 route optimization.




Larsson, et al.          Expires August 24, 2004               [Page 16]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   The operation of ISATAP is independent of Mobile IPv6.  This means
   that Mobile IPv6 signaling will take place after ISATAP router
   discovery (e.g. discovery of ISATAP router IPv4 address).  The
   handoff latency will therefore depend on the method for ISATAP router
   discovery.  This will generate at least one signalling roundtrip
   (within the access network) before address configuration and Mobile
   IPv6 signalling can take place.

   Overhead in the ISATAP case, compared to native IPv6, includes IPv4
   encapsulation of router solicitations, router advertisements, Mobile
   IPv6 signaling and Mobile IPv6 traffic, i.e. generating an additional
   20 bytes in overhead per message (between the mobile node and the
   ISATAP router).

   While ISATAP enables Mobile IPv6 signaling and tunneling over IPv4,
   it does not solve the host-internal issue of providing Mobile IPv6
   transport for IPv4 applications.  This would require extensions to
   Mobile IPv6 (MIPv6x).  Given such extensions, Mobile IPv6 with ISATAP
   solves scenarios 3-4 and 7-8 in Table 1 (with IPv6 transport
   network), scenarios 11-12 in Table 2, scenarios i-p in Table 3 and
   scenarios gg-ll in Table 4.

6.5  MIPv6 with Teredo and 6to4

   Another alternative for deployment case II is MIPv6 with Teredo and
   6to4.  Teredo would be used when the mobile node would find itself
   behind a NAT, while 6to4 would be used otherwise.  This solution
   requires that a MN using regular MIPv6 for mobility be enhanced with
   both a Teredo client implementation and a local 6to4 implementation.

   MIPv6 in combination with Teredo covers scenarios 11-12 of Table 2,
   while MIPv6 in combination with a 6to4 implementation in the local
   stack covers scenario 3-4 in Table 1.  Scenario 8 is covered natively
   by MIPv6.  Scenario 7 is not solved by any combination of regular
   MIPv6 and other transition mechanisms - it requires an extension to
   MIPv6.  Given such an extension to MIPv6 (MIPv6x), this solution
   would also cover scenarios i-p in Table 3 and scenarios gg-ll in
   Table 4.

   During handoff to a public IPv4 address, the 6to4 stack will
   construct a 6to4 IPv6 address after the public IPv4 address has been
   acquired, and MIPv6 will use that address to communicate with the
   IPv6 home network and the MIPv6 home agent.  There are no added
   registration messages.  The transport overhead will be 20 bytes.

   In the Teredo case, the mobile node would be pre-configured with the
   address of its Teredo server, and would not have to search for it.




Larsson, et al.          Expires August 24, 2004               [Page 17]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   On the other hand, in the Teredo case the mobile node will have to
   run the Teredo qualification procedure, which may require as little
   as one additional roundtrip, but in the worst case may require as
   much as 12 seconds plus one round-trip in order to determine the type
   of NAT.  The Teredo client may also have to send a Teredo bubble
   through the NAT before traffic can be received from a correspondent
   node, which we count as yet another half roundtrip, compared with
   MIPv6.

   Route optimization for MIPv6 works when MIPv6 is used with Teredo/
   6to4, but note that there may still be a triangular routing through a
   Teredo Relay, if the host with which the mobile node is communicating
   is not itself Teredo enabled.

6.6  MIPv6 with STEP

   STEP in combination with Mobile IPv6 [RFC3775] provides mobility
   support for deployment case II (i.e.  MIPv6 based).  Deployment-wise,
   this solution will require a tunnel router in the ISP's network that
   provides IPv6 connectivity, and a client in MN that handles e.g.
   discovery of the tunnel router.  This solution allows Mobile IPv6
   route optimization.

   The operation of STEP is independent of Mobile IPv6.  This means that
   Mobile IPv6 signaling will take place after the discovery of the IPv4
   tunnel end-point address.  The handoff latency will therefore depend
   on the method for tunnel router discovery.  This will generate at
   least one signalling roundtrip before address configuration and
   Mobile IPv6 signalling can take place.

   Overhead in the STEP case, compared to native IPv6, includes IPv4 or
   UDP encapsulation of router solicitations, router advertisements,
   Mobile IPv6 signaling and Mobile IPv6 traffic, i.e. generating an
   additional 20 (IPv4 encapsulation) or 28 bytes (UDP encapsulation) in
   overhead per message.

   While STEP enables Mobile IPv6 signaling and tunneling over IPv4, it
   does not solve the host-internal issue of providing Mobile IPv6
   transport for IPv4 applications.  This would require extensions to
   Mobile IPv6.  Given such extensions (MIPv6x), Mobile IPv6 with STEP
   solves scenarios 3-4 and 7-8 in Table 1 (with IPv6 transport
   network), scenarios 11-12 in Table 2, scenarios i-p in Table 3 and
   scenarios gg-ll in Table 4.

6.7  MIPv6 or MIPv4 with TSP

   Assuming that TSP is deployed, it could be used to set up IPv6-in-
   IPv4 or IPv6-in-UDP-in-IPv4 tunnels to allow MIPv6 mobile nodes



Larsson, et al.          Expires August 24, 2004               [Page 18]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   connectivity over IPv4 access networks, hereby addressing deployment
   case II.  With an extension to the MIPv6 host, allowing MIPv6
   transport for IPv4 sockets, this solution covers scenarios 3-4, 7-8
   in Table 1, 11-12 in Table 2, i-p in Table 3 and gg-ll in Table 4.

   Deployment case I can be addressed by using TSP to set up IPv4-in-
   IPv6 tunnels.  With an extension to the MIPv4 host (MIPv4x), allowing
   MIPv4 transport for IPv6 sockets, this solution covers scenarios 1-2,
   5-6 in Table 1, 9-10 in Table 2, a-h in Table 3 and aa-ff in Table 4.

   In addition to deployment of TSP clients and servers, these solutions
   requires deployment of SASL [RFC2222] for authentication of the
   tunnel setup signaling.  The signaling between client and server to
   set up a tunnel (including SASL authentication) amounts to three
   roundtrips.  Depending on deployment, a client may also need to
   locate a broker/server, thereby generating more signaling roundtrips.
   Once the signaling between the TSP client and server is finished,
   MIPv4/MIPv6 registration can start.  Thus, in total, this method
   generates at least three signaling roundtrips before MIPv4/MIPv6
   signaling starts.

   In case of MIPv6, if the mobile node is located in an IPv4 access
   network, the MIPv6 binding update messages are sent either through an
   IPv6-in-IPv4 tunnel, generating an overhead of 20 bytes (IPv4 header)
   or through an IPv6-in-UDP-in-IPv4 tunnel, generating an overhead of
   28 bytes (IPv4 plus UDP header), compared to native MIPv6.
   Similarly, the transport overhead amounts to 20 or 28 bytes.

   In case of MIPv4, when the mobile node is located in an IPv6 access
   network, the MIPv4 registration messages are sent through an IPv4-in-
   IPv6 tunnel, generating an overhead of 40 bytes (IPv6 header),
   compared to native MIPv4.  This overhead applies to the transport as
   well.

   Theoretically, MIPv6 with TSP allows for MIPv6 route optimization
   through the TSP server.  Depending on where the server is located
   though, compared to the MN and the CN, the route may be more or less
   triangular.

7.  Conclusions

   We have outlined network and handoff scenarios for mobility over IPv4
   (public and private) and IPv6 address spaces.  We have also listed
   and commented on related work and evaluated possible solutions for
   solving mobility in these scenarios in a way compliant with Mobile
   IP.

   In general terms, three problems need to be solved: (1) tunneling of



Larsson, et al.          Expires August 24, 2004               [Page 19]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   packets over the access network (IPv4 over IPv6, or IPv6 over IPv4);
   (2) NAT traversal; and (3) enhancement of MIPv4 to carry IPv6
   payloads and/or enhancement of MIPv6 to carry IPv4 payloads.  A
   solution for problem (3) needs to be included in all proposed
   solutions, except "Dual-stack MIPv4-MIPv6" where this is already
   solved.

   From the evaluations, we can draw the following conclusions:
   o  Solution Dual-stack MIPv4-MIPv6 fulfills deployment case III.
   o  Solution Enhanced MIPv4 fulfills deployment case I.
   o  Solution MIPv4 with TSP fulfills deployment case I.
   o  Solution Enhanced MIPv6 partly fulfills deployment case II.  NAT
      traversal is not supported.
   o  Solution MIPv6 with ISATAP fulfills deployment case II.
   o  Solution MIPv6 with Teredo and 6to4 fulfills deployment case II.
   o  Solution MIPv6 with STEP fulfills deployment case II.
   o  Solution MIPv6 with TSP fulfills deployment case II.

   For these solutions, we can list the following properties:
   o  Solution Dual-stack MIPv4-MIPv6 generates two extra signaling
      messages at handoff but no additional handoff latency.  It
      requires implementation of double mobility protocols including
      authentication and subscription management.
   o  Solution Enhanced MIPv4 generates no additional handoff latency.
   o  Solution MIPv4 with TSP generates at least 3 extra signaling
      roundtrips at handoff.
   o  Solution Enhanced MIPv6 generates no additional handoff latency.
      If extended to support NAT traversal, this solution would generate
      additional overhead when NAT traversal would be in use.  Also,
      this solution does not allow for route optimization.
   o  Solution MIPv6 with ISATAP generates at least 1 extra signaling
      roundtrip at handoff.
   o  Solution MIPv6 with Teredo and 6to4 generates at least 1
      additional signaling roundtrips at handoff, and has a worst case
      scenario of 12 seconds plus one roundtrip during handoff.
   o  Solution MIPv6 with STEP generates at least 1 extra signaling
      roundtrip at handoff.
   o  Solution MIPv6 with TSP generates at least 3 extra signaling
      roundtrips at handoff.

   In general, all the described solutions generate an additional 20 or
   40 bytes transport overhead, depending on whether traffic is tunneled
   over IPv4 or IPv6 networks.  The Teredo-based, STEP-based and TSP-
   based solutions, though, generate 28 bytes of transport overhead for
   NAT traversal (IPv4 header and UDP header).

   From this, we draw the following conclusions:




Larsson, et al.          Expires August 24, 2004               [Page 20]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   Deployment case I is solved by "Enhanced MIPv4".  This solution also
   adds minimal handoff latency and transport overhead, compared to
   native MIPv4.  Deployment case I can also be solved by "MIPv4 with
   TSP".

   Deployment case II can either be solved by standardizing extensions
   to Mobile IPv6, i.e.  "Enhanced MIPv6" together with a solution for
   NAT traversal, or by Mobile IPv6 combined with transition mechanisms.
   In the latter case, there are three main solutions: "MIPv6 with
   ISATAP", "MIPv6 with Teredo and 6to4", "MIPv6 with STEP" or MIPv6
   with TSP".  The performance of these solutions largely depend on the
   deployment and performance of the different transition mechanisms.

   The solution "Dual-stack MIPv4-MIPv6" requires twice the amount of
   implementation as solution "Enhanced MIPv4", while providing
   approximately the same performance in terms of handoff latency and
   transport overhead.  This solution is, however, the only one
   supporting deployment case III.

8.  Security Considerations

   This document defines no new protocols for the internet, and has no
   direct security implications.  Note however that there are a number
   of security implications in dealing with NAT traversal.  In the case
   of Teredo [I-D.huitema-v6ops-teredo] and MIPv4 with NAT traversal
   [RFC3519], these security considerations are well described in the
   respective documents.

   However, if it is decided to enhance MIPv6 with the extensions and
   mechanisms necessary to function in an IPv4 environment, the same
   care has to be taken with any NAT traversal mechanism for MIPv6.

9.  IANA Considerations

   This document does not require any new number assignments from IANA,
   and does not define any new numbering spaces to be administered by
   IANA.

   RFC-Editor: Please remove this section before publication.

10.  References

10.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.





Larsson, et al.          Expires August 24, 2004               [Page 21]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


10.2  Informative References

   [RFC2222]  Myers, J., "Simple Authentication and Security Layer
              (SASL)", RFC 2222, October 1997.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
              Translation - Protocol Translation (NAT-PT)", RFC 2766,
              February 2000.

   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
              August 2002.

   [RFC3024]  Montenegro, G., "Reverse Tunneling for Mobile IP,
              revised", RFC 3024, January 2001.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3519]  Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
              Network Address Translation (NAT) Devices", RFC 3519,
              May 2003.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC3904]  Huitema, C., Austein, R., Satapati, S., and R. van der
              Pol, "Evaluation of IPv6 Transition Mechanisms for
              Unmanaged Networks", RFC 3904, September 2004.

   [I-D.ietf-ngtrans-moving]
              Tsao, S., "Moving in a Dual Stack Internet",
              draft-ietf-ngtrans-moving-01 (work in progress),
              March 2002.

   [I-D.tsirtsis-dsmip-problem]
              Tsirtsis, G. and H. Soliman, "Mobility management for Dual
              stack mobile nodes A Problem Statement",
              draft-tsirtsis-dsmip-problem-03 (work in progress),
              October 2004.

   [I-D.soliman-v4v6-mipv4]
              Soliman, H. and G. Tsirtsis, "Dual Stack Mobile IPv6",
              draft-soliman-v4v6-mipv4-01 (work in progress),
              October 2004.



Larsson, et al.          Expires August 24, 2004               [Page 22]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   [I-D.tsirtsis-v4v6-mipv4]
              Tsirtsis, G. and H. Soliman, "Dual Stack Mobile IPv4",
              draft-tsirtsis-v4v6-mipv4-00 (work in progress),
              August 2003.

   [I-D.kahng-mobileip-moving6to4]
              Kahng, H., "An interconnection mechanism of Mobile IPv6
              using 6to4", draft-kahng-mobileip-moving6to4-00 (work in
              progress), September 2003.

   [I-D.huitema-v6ops-teredo]
              Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              NATs", draft-huitema-v6ops-teredo-04 (work in progress),
              January 2005.

   [I-D.ietf-ngtrans-isatap]
              Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
              "Intra-Site Automatic Tunnel Addressing Protocol
              (ISATAP)", draft-ietf-ngtrans-isatap-24 (work in
              progress), January 2005.

   [I-D.savola-v6ops-conftun-setup]
              Savola, P., "Simple IPv6-in-IPv4 Tunnel Establishment
              Procedure (STEP)", draft-savola-v6ops-conftun-setup-02
              (work in progress), January 2004.

   [I-D.blanchet-v6ops-tunnelbroker-tsp]
              Parent, F. and M. Blanchet, "IPv6 Tunnel Broker with the
              Tunnel Setup Protocol(TSP)",
              draft-blanchet-v6ops-tunnelbroker-tsp-01 (work in
              progress), June 2004.

   [I-D.ietf-v6ops-3gpp-analysis]
              Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
              Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in
              progress), October 2004.

   [I-D.satapati-v6ops-natpt-applicability]
              Satapati, S., "NAT-PT Applicability",
              draft-satapati-v6ops-natpt-applicability-00 (work in
              progress), October 2003.

   [I-D.thubert-nemo-ipv4-traversal]
              Thubert, P., Molteni, M., and P. Wetterwald, "IPv4
              traversal for MIPv6 based Mobile Routers",
              draft-thubert-nemo-ipv4-traversal-01 (work in progress),
              May 2003.




Larsson, et al.          Expires August 24, 2004               [Page 23]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   [I-D.tsao-mobileip-dualstack-model]
              Tsao, S. and W. Boehm, "Mobility Support for IPv4 and IPv6
              Interconnected Networks",
              draft-tsao-mobileip-dualstack-model-02.txt (work in
              progress), February 2000.


Authors' Addresses

   Tony Larsson
   Ericsson
   Torshamnsgatan 23
   SE-164 80 Stockholm
   Sweden

   Email: tony.larsson@ericsson.com


   Eva Gustafsson
   Ericsson
   Torshamnsgatan 23
   SE-164 80 Stockholm
   Sweden

   Email: eva.gustafsson@ericsson.com


   Henrik Levkowetz
   Ericsson
   Torsgatan 71
   Stockholm  S-113 37
   SWEDEN

   Phone: +46 708 32 16 08
   Email: henrik@levkowetz.com
















Larsson, et al.          Expires August 24, 2004               [Page 24]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


Appendix A.  Supported scenarios per solution

   Table 5: This table indicates which of the network scenarios 1-12 are
   supported by each of the proposed solutions.  Note that the solutions
   for deployment case II (MIPv6-based) are assumed to include
   mechanisms in the host to provide MIPv6 transport for IPv4 sockets
   (MIPv6x).

   +----+------+------+-------+------+--------+--------+-------+-------+
   |    |  DS  | Enh. | MIP4x | Enh. | MIP6x+ | MIP6x+ | MIP6x | MIP6x |
   |    | MIP4 | MIP4 |  +TSP | MIP6 | ISATAP | Teredo | +STEP |  +TSP |
   |    |  /6  | (xo) |       | (xo) |        |  +6to4 |       |       |
   +----+------+------+-------+------+--------+--------+-------+-------+
   |  1 |   x  |   x  |   x   |      |        |        |       |       |
   |  2 |   x  |   x  |   x   |      |        |        |       |       |
   |  3 |   x  |      |       |   x  |    x   |    x   |   x   |   x   |
   |  4 |   x  |      |       |   x  |    x   |    x   |   x   |   x   |
   |  5 |   x  |   x  |   x   |      |        |        |       |       |
   |  6 |   x  |   x  |   x   |      |        |        |       |       |
   |  7 |   x  |      |       |   x  |    x   |    x   |   x   |   x   |
   |  8 |   x  |      |       |   x  |    x   |    x   |   x   |   x   |
   |  9 |   x  |   x  |   x   |      |        |        |       |       |
   | 10 |   x  |   x  |   x   |      |        |        |       |       |
   | 11 |      |      |       |      |    x   |    x   |   x   |   x   |
   | 12 |      |      |       |      |    x   |    x   |   x   |   x   |
   +----+------+------+-------+------+--------+--------+-------+-------+

























Larsson, et al.          Expires August 24, 2004               [Page 25]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   Table 6: This table indicates which of the handoff scenarios a-p and
   aa-ll are supported by each of the proposed solutions.  Note that the
   solutions for deployment case II (MIPv6-based) are assumed to include
   mechanisms in the host to provide MIPv6 transport for IPv4 sockets
   (MIPv6x).

   +----+------+------+-------+------+--------+--------+-------+-------+
   |    |  DS  | Enh. | MIP4x | Enh. | MIP6x+ | MIP6x+ | MIP6x | MIP6x |
   |    | MIP4 | MIP4 |  +TSP | MIP6 | ISATAP | Teredo | +STEP |  +TSP |
   |    |  /6  | (xo) |       | (xo) |        |  +6to4 |       |       |
   +----+------+------+-------+------+--------+--------+-------+-------+
   |  a |   x  |   x  |   x   |      |        |        |       |       |
   |  b |   x  |   x  |   x   |      |        |        |       |       |
   |  c |   x  |   x  |   x   |      |        |        |       |       |
   |  d |   x  |   x  |   x   |      |        |        |       |       |
   |  e |   x  |   x  |   x   |      |        |        |       |       |
   |  f |   x  |   x  |   x   |      |        |        |       |       |
   |  g |   x  |   x  |   x   |      |        |        |       |       |
   |  h |   x  |   x  |   x   |      |        |        |       |       |
   |  i |   x  |      |       |   x  |    x   |    x   |   x   |   x   |
   |  j |   x  |      |       |   x  |    x   |    x   |   x   |   x   |
   |  k |   x  |      |       |   x  |    x   |    x   |   x   |   x   |
   |  l |   x  |      |       |   x  |    x   |    x   |   x   |   x   |
   |  m |   x  |      |       |   x  |    x   |    x   |   x   |   x   |
   |  n |   x  |      |       |   x  |    x   |    x   |   x   |   x   |
   |  o |   x  |      |       |   x  |    x   |    x   |   x   |   x   |
   |  p |   x  |      |       |   x  |    x   |    x   |   x   |   x   |
   | aa |   x  |   x  |   x   |      |        |        |       |       |
   | bb |   x  |   x  |   x   |      |        |        |       |       |
   | cc |   x  |   x  |   x   |      |        |        |       |       |
   | dd |   x  |   x  |   x   |      |        |        |       |       |
   | ee |   x  |   x  |   x   |      |        |        |       |       |
   | ff |   x  |   x  |   x   |      |        |        |       |       |
   | gg |      |      |       |      |    x   |    x   |   x   |   x   |
   | hh |      |      |       |      |    x   |    x   |   x   |   x   |
   | ii |      |      |       |      |    x   |    x   |   x   |   x   |
   | jj |      |      |       |      |    x   |    x   |   x   |   x   |
   | kk |      |      |       |      |    x   |    x   |   x   |   x   |
   | ll |      |      |       |      |    x   |    x   |   x   |   x   |
   +----+------+------+-------+------+--------+--------+-------+-------+


Appendix B.  Transport overhead per solution

   The following lists transport overhead for the different solutions,
   sorted after deployment cases.

   Deployment case I (MIPv4-based).



Larsson, et al.          Expires August 24, 2004               [Page 26]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   o  Solution Enhanced MIPv4 adds 40 bytes transport overhead (IPv6
      header), compared to native MIPv4.
   o  Solution MIPv4 with TSP adds 40 bytes transport overhead (IPv6
      header), compared to native MIPv4.

   Deployment case II (MIPv6-based).
   o  Solution Enhanced MIPv6 adds 20 bytes transport overhead (IPv4
      header), compared to native MIPv6.
   o  Solution MIPv6 with ISATAP adds 20 bytes transport overhead (IPv4
      header) compared to native MIPv6, but only in the access network.
   o  Solution MIPv6 with Teredo adds 28 bytes transport overhead (IPv4
      header + UDP header) compared to native MIPv6.
   o  Solution MIPv6 with 6to4 adds zero transport overhead, compared to
      native MIPv6.
   o  Solution MIPv6 with STEP adds 20/28 bytes transport overhead (IPv4
      or IPv4 + UDP header), compared to native MIPv6.
   o  Solution MIPv6 with TSP adds 20/28 bytes transport overhead (IPv4
      or IPv4 + UDP header), compared to native MIPv6.

   Deployment case III (MIPv4-MIPv6).
   o  Solution Dual-stack MIPv4-MIPv6 adds zero transport overhead,
      compared to native MIPv4 or native MIPv6, respectively.

Appendix C.  Registration message roundtrips per solution

   The following lists the number of registration message roundtrips for
   the different solutions, sorted after deployment cases.

   Deployment case I (MIPv4-based).
   o  Solution Enhanced MIPv4 adds zero roundtrips, compared to native
      MIPv4.
   o  Solution MIPv4 with TSP adds at least 3 roundtrips, compared to
      native MIPv4.

   Deployment case II (MIPv6-based).
   o  Solution Enhanced MIPv6 adds zero roundtrips, compared to native
      MIPv6.
   o  Solution MIPv6 with ISATAP adds at least 1 roundtrip, compared to
      native MIPv6.
   o  Solution MIPv6 with Teredo and 6to4 adds at least 1 roundtrip in
      the Teredo case, compared to native MIPv6.
   o  Solution MIPv6 with STEP adds at least 1 roundtrip, compared to
      native MIPv6.
   o  Solution MIPv6 with TSP adds at least 3 roundtrips, compared to
      native MIPv6.

   Deployment case III (MIPv4-MIPv6).




Larsson, et al.          Expires August 24, 2004               [Page 27]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


   o  Solution Dual-stack MIPv4-MIPv6 adds zero roundtrips, compared to
      native MIPv4 or native MIPv6, respectively.

















































Larsson, et al.          Expires August 24, 2004               [Page 28]


Internet-Draft        MIPv4 in IPv6 / MIPv6 in IPv4        February 2004


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 (2004).  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.




Larsson, et al.          Expires August 24, 2004               [Page 29]


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