NETLMM Working Group                                         R. Wakikawa
Internet-Draft                                           Keio University
Intended status: Standards Track                           S. Gundavelli
Expires: November 2, 2007 January 10, 2008                                          Cisco
                                                            July 9, 2007

                   IPv4 Support for Proxy Mobile IPv6
              draft-ietf-netlmm-pmip6-ipv4-support-00.txt
              draft-ietf-netlmm-pmip6-ipv4-support-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 2, 2007. January 10, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document specifies extensions to the Proxy Mobile IPv6 protocol
   [ID-PMIP6] for supporting IPv4.  The scope of the IPv4 support in
   Proxy Mobile IPv6 includes the support for the mobile node's IPv4
   home address mobility and for supporting the scenario where the local
   mobility anchor and the mobile access gateway are separated by an
   IPv4 transport network.  The solution primarily leverages the
   extensions defined in Dual Stack Mobile IPv6 specification [ID-
   DSMIP6] for achieving this.

Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Conventions & Terminology  . . . . . . . . . . . . . . . . . .  6
     2.1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6

   3.  IPv4 Home Address Mobility Support . . . . . . . . . . . . . .  7
     3.1.  IPv4 Home Address Assignment . . . . . . . . . . . . . . .  7
     3.2.  Extensions to Conceptual Data Structure  . . . . . . . . .  9
     3.3.  Mobility Options . . . . . . . . . . . . . . . . . . . . .  9
     3.4.  Mobile Access Gateway Operation  . . . . . . . . . . . . . 10  9
     3.5.  Local Mobility Anchor Operation  . . . . . . . . . . . . . 11

   4.  IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 13
     4.1.  Mobility Options . . . . . . . . . . . . . . . . . . . . . 13
     4.2.  Extensions to Conceptual Data Structure  . . . . . . . . . 13
     4.3.  NAT Detection  . . . . . . . . . . . . . . . . . . . . . . 14
     4.4.  Mobile Access Gateway Operation  . . . . . . . . . . . . . 14
     4.5.  Local Mobility Anchor Operation  . . . . . . . . . . . . . 16
     4.6.  Tunnel Management  . . . . . . . . . . . . . . . . . . . . 18

   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19

   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20

   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21

   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21

   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 22

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
   Intellectual Property and Copyright Statements . . . . . . . . . . 25

1.  Overview

   The transition from IPv4 to IPv6 is a long process and during this
   period of transition, both the protocols will be enabled over the
   same infrastructure.  Thus, it is reasonable to assume that the
   mobile node, mobile access gateway and the local mobility anchor are
   both IPv4 and IPv6 enabled and further it is also reasonable to
   expect the same mobility infrastructure to provide both IPv4 and IPv6
   address mobility for a mobile node.  The motivation and scope of IPv4
   support in Mobile IPv6 is summraized summarized in [ID-DSMIP6-PS].

   The Proxy Mobile IPv6 base specification [ID-PMIP6] defines a
   network-based mobility management protocol.  The protocol specifies a
   solution for providing IPv6 home address mobility for a mobile node
   and over an IPv6 transport network separating the entities involved
   in the mobility management.  The  This specification defines extensions defined in this document
   are for extending IPv4 support to
   the Proxy Mobile IPv6 protocol [ID-
   PMIP6]. for supporting IPv4.  The scope of
   these efforts include the support for IPv4 related extensions are the following:

   o  IPv4 Home Address Mobility: A mobile node operating in IPv4-only
      mode or in a dual-stack mode should be able to obtain an IPv4 home
      address and roam anywhere in that Proxy Mobile IPv6 domain.

   o  IPv4 Transport Network Support: The transport network between the
      local mobility anchor and the mobile access gateway is an IPv4
      network and further the local mobility anchor or the mobile access
      gateway may be using IPv4 private addresses and with NAT
      translation devices on the path

   The DSMIP6 Dual-Stack Mobile IPv6 specification [ID-DSMIP6], extends IPv4
   home address mobility and IPv4 transport network support to the
   Mobile IPv6 protocol [RFC-3775].  The solution specified in this
   document leverages the DSMIP6 work and extends the extensions for extending IPv4 feature support
   to the Proxy Mobile IPv6 protocol.  The protocol semantics, processing
   logic and mobility header options, such as IPv4 home address option,
   IPv4 address acknowledgment option and NAT detection option, defined
   in the DSMIP6 specification, are all applied for Proxy Mobile IPv6
   protocol.  As specified in DSMIPv6, these two features, IPv4 Home
   Address Mobility support and IPv4 transport support, are independent
   of each other and implementors implementers may choose to implement any one or
   both of these features.  Since this specification also inherits  Unlike in DSMIP6, a mobile node in Proxy
   Mobile domain is NOT required to have an IPv6 home address for
   obtaining IPv4 home address mobility.

   As specified in the Proxy Mobile IPv6 specification [ID-PMIP6], only point to point this
   specification assumes that the link is assumed between a the mobile node access gateway
   and the local mobility anchor is a mobile access gateway. point-to-point link.  This
   specification also assumes that the local mobility anchor and the
   mobile access gateway are both IPv6 capabled capable and IPv6 enabled,
   irrespective of enabled and even
   when the type of transport network (IPv4 or IPv6),
   connecting these two entities. between the mobile access gateway and a local
   mobility anchor is IPv4-only network.  The signaling protocol is
   fundamentally
   primarily based on Mobile IPv6 in this document. and hence the entities providing the
   network-based mobility management service must be IPv6 enabled.

   Figure 1 illustrates a Proxy Mobile IPv6 domain supporting IPv4 home
   address mobility and IPv4 transport network features.  The mobile
   nodes MN1, MN2 and MN3 can be operating in IPv4-only, IPv6-only or
   dual-stack mode, and the transport network between the local mobility
   anchor and the mobile access gateway may be an IPv6 network or an
   IPv4 network.  Further, when the transport network is IPv4, either
   the local mobility anchor or the mobile access gateway, or both can
   be behind a NAT translation device and configured with an IPv4
   private address.

               +----+                +----+
               |LMA1|                |LMA2|
               +----+                +----+
   IPv4-LMAA1 -> |                      | <-- IPv4-LMAA2
                 |                      |
                 \\                    //\\
                [NAT]                 //  \\
                   \\                //    \\
                +---\\------------- //------\\----+
               (     \\  IPv4/IPv6 //        \\    )
               (      \\  Network //          \\   )
                +------\\--------//------------\\-+
                        \\      //              \\
                         \\    //               [NAT]
                          \\  //                  \\
         IPv4-Proxy-CoA1--> |                      | <-- IPv4-Proxy-CoA2
                         +----+                 +----+
                         |MAG1|-----[MN2]       |MAG2|
                         +----+    |            +----+
                           |       |               |
         IPv4-MN-HoA1 -->  |     IPv4-MN-HoA2      | <-- IPv4-MN-HoA3
                         [MN1]                   [MN3]

               Figure 1: IPv4 support for Proxy Mobile IPv6

2.  Conventions & Terminology

2.1.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC-2119].

2.2.  Terminology

   All the mobility related terms used in this document are to be
   interpreted as defined in Mobile IPv6 specification [RFC-3775],
   DSMIP6 specification [ID-DSMIP6] and Proxy Mobile IPv6 specification
   [ID-PMIP6].  In addition the document introduces the following terms.

   IPv4 Proxy Care-of Address (IPv4-Proxy-CoA)

      The IPv4 Care-of Address that is configured on the interface of
      the mobile access gateway and is the transport endpoint of the
      tunnel between a local mobility anchor and a mobile access
      gateway.  However, when the configured address is a private IPv4
      address and with a NAT device in the path to the local mobility
      anchor, the care-of address as seen by the local mobility anchor
      will be the address allocated by the NAT device for the mobility
      session.

   IPv4 Local Mobility Anchor Address (IPv4-LMAA)

      The global IPv4 address that is typically configured on the
      interface of a local mobility anchor and is the transport endpoint
      of the tunnel between a local mobility anchor and a mobile access
      gateway.  This is the address to where a mobile access gateway
      sends proxy binding update messages.  If a local mobility anchor
      is configured behind NAT, IPv4-LMAA is the IPv6 global address of
      the NAT box.  According to Section 2.1 of [ID-DSMIP6], two options
      are introduced for the case of the home agent being behind the NAT
      box.  When we interpret this two options for Proxy Mobile IPv6, it
      goes following. 1) configure a public IPv4 address for each local
      mobility anchor on the NAT box. 2) configure one public address
      and make the local mobility anchors share the public address.

3.  IPv4 Home Address Mobility Support

   Using the extensions defined in this specification, a mobile node
   operating in an IPv4-only or dual-stack mode will be able to obtain
   an IPv4 address (IPv4-MN-HoA) and will be able to roam in that Proxy
   Mobile IPv6 domain using that address.  Although IPv6 home address is
   always required in [ID-DSMIP6], this specification does not mandate
   IPv6 home address unless a mobile node wants the IPv6 home address.
   The network will provide mobility to that mobile node in that entire
   domain.  And further, the network will ensure that the mobile node
   will always be able to obtain the same IPv4 address, as it moves
   between access links and as long as the mobile node is in the scope
   of that Proxy Mobile IPv6 domain.

3.1.  IPv4 Home Address Assignment

   A mobile node on attaching to an access link connected to a mobile
   access gateway, and if the network allows the mobile node for IPv4
   home address mobility service, the mobile node using any of the IPv4
   address configuration procedures, such as DHCP, IPCP or IKEv2 that
   are supported on that access link, will be able to obtain its IPv4
   home address configuration.  In addition to this, other address
   configuration mechanisms including static configuration methods
   specific to the access link may also be in place.  The IPv4 home address configuration
   includes the IPv4 home address, the IPv4 home network prefix and IPv4
   home network prefix length.  In this
   specification, we

   Figure 2 shows the operational sequence of the home address mobility
   support following static and dynamic assignment
   schemes.

   o  Static when a local mobility anchor assigns an IPv4 Home Address Assignment: When
   dynamically to a mobile node is
      configured with a static IPv4 home address, the IPv4 home address
      information MUST be stored node.  All mobile access gateways SHOULD
   support minimal functionality of DHCP server in order to send DHCP
   offer and and acknowledgment messages to the mobile node's policy profile. node in reply to
   the DHCP discovery and request messages.  The mobile access gateway where the
   is seen as a DHCP server from a mobile node attached node, but it actually obtains
   the static IPv4 home address from the policy profile.  The for each mobile
      access gateway MUST set node from the local mobility
   anchor during proxy binding procedure (set 0.0.0.0 in the known IPv4 home prefix to the IPv4
   Home Address field and the Pref field of the IPv4 home address option [ID-DSMIP6].  This option is carried by a proxy binding
      update described in [ID-PMIP6].

   o  Dynamic IPv4 Home Address Assignment from Local Mobility Anchor:
      If a local mobility anchor manages the IPv4 home address
      allocation, a mobile access gateway requests dynamic IPv4 home
      address allocation to the local mobility anchor as described in
      [ID-DSMIP6].
   [ID-DSMIP]).  The mobile access gateway SHOULD support minimal
      functionality of DHCP server MUST return its own IP
   address in order to send the 'server identifier' option when sending DHCP offer and and
      acknowledgment messages
   message to the mobile node.  Thus, whenever the mobile node in reply to changes
   the DHCP
      discovery and request messages.  The attached mobile access gateway is seen
      as DHCP gateway, this server from a mobile node, but it actually obtains the
      IPv4 home address for each mobile node from the local mobility
      anchor during proxy binding procedure.  Figure 2 shows the
      operational sequence identifier must be
   updated.  The detail can be found in Section 3.4.  Any information
   carried in DHCP options such as addresses of the home address mobility support< domain name server, time
   server, lpr server, etc.  MUST be configured in this
      case. all the mobile access
   gateway (i.e.  DHCP server) if necessary.  If IPCP is used for
   address assignment, DHCP events in Figure 2 are replaced by PPP
   events.

     MN      MAG   MAG(DHCPS)  LMA
      |------>|        |    1. DHCP discovery
      |       |------->|    2. Proxy Binding Update
      |       |<-------|    3. Proxy Binding Acknowledgement (IPv4HoA)
      |       |========|    4. Tunnel/Route Setup*
      |<------|        |    5. DHCP offer (IPv4 HoA) **
      |------>|        |    6. DHCP request (IPv4 HoA)
      |<------|        |    7. DHCP acknowledgement
      |       |        |
      * Tunnel/Route setup(no.4) and DHCP offer/request/ack(no.5-7)
        are processed in parallel.
     ** MAG SHOULD return its own IP address in the 'server identifier'
        option when sending DHCP offer.

        Figure 2: An example when LMA assigns an IPv4 home address

   In addition to this, other address configuration mechanisms including
   static configuration methods specific to the access link or dynamic
   configuration from the DHCP server (without local mobility anchor
   involvmenet) may also be in place.  Several other assignment schems
   are listed:

   o  Dynamic  Static IPv4 Home Address Assignment from DHCP Server: If DHCP is
      used for the IPv4 home address allocation, Assignment: When a mobile access gateway
      or specifically a DHCP relay agent on the link will ensure the
      mobile node is assigned an address from its home network prefix,
      by marking the DHCP request
      configured with a static IPv4 home address, the mobile node's IPv4 home
      network prefix hint.  A DHCP relay and a mobile access gateway can address
      information MUST be co-located. stored in the mobile node's policy profile.
      The mobile access gateway learns where the mobile node attached obtains
      the static IPv4 home address from the DHCP reply and sends that information to the policy profile.  The mobile node by DHCP offer message.  Meanwhile, it notifies
      access gateway MUST set the
      assigned known IPv4 home address by an prefix to the IPv4
      Home Address field and the Pref field of the IPv4 home address
      option in [ID-DSMIP6].  This option is carried by a proxy binding
      update to described in [ID-PMIP6].

   o  Dynamic IPv4 Home Address Assignment from DHCP Server: If DHCP is
      used for the local mobility anchor. IPv4 home address allocation, a DHCP server and a
      DHCP relay agent on the link will ensure the mobile node is
      assigned an address from its home network prefix.  In this case,
      the local mobility anchor does not allocate any address, but only deals with route setup and tunnel
      setup for the requested home address.  Note that all the IPv4 home addresses managed in the
      DHCP server must be reachable via local mobility anchor so that
      local mobility anchor intercepts packets meant for an IPv4 home
      address and tunnels them to the mobile node via corresponding
      mobile access gateway.  More remarks can be found in Section 6.
      Figure 3 are the sequence of the home address mobility support.

     MN   MAG(DHCPR) DHCPS    LMA
      |------>|------->|       |  1. DHCP discovery and Relay
      |       |<-------|       |  2. DHCP offer (IPv4 HoA)
      |       |--------------->|  3. Proxy Binding Update
      |       |<---------------|  4. Proxy Binding Acknowledgement
      |       |================|  5. Tunnel/Route Setup
      |<------|        |       |  6. DHCP offer (IPv4 HoA) Relay
      |------>|------->|       |  7. DHCP request (IPv4 HoA) and Relay
      |<------|<-------|       |  8. DHCP acknowledgement and Relay
      |       |        |       |

      DHCPS: DHCP Server
      DHCPR:  A DHCP Relay
      * Tunnel setup(no.5) relay and a mobile
      access gateway should be co-located.  Otherwise, the mobile access
      gateway MUST learn the IPv4 home address from the DHCP offer/request/ack(no.6-8)
        are processed in parallel.

      Figure 3: An example when DHCP Server assigns reply.
      Meanwhile, it notifies the assigned IPv4 home address by an IPv4
      home address option in a proxy binding update to the local
      mobility anchor.  Some remarks can be found in Section 6.

3.2.  Extensions to Conceptual Data Structure

   There are certain extensions defined in DSMIP specification [DSMIP6]
   for supporting IPv4 home address mobility support.  A mobile node can
   obtain only IPv4 home address by this specification, while DSMIP
   requires IPv6 home address for IPv4 home address support.  Thus, a
   mobile access gateway and a local mobility agent MUST create a
   binding update list and a binding cache only for IPv4 home address
   assigned to a mobile node.

3.3.  Mobility Options

   For supporting the IPv4 home address mobility, the following options
   are required from the DSMIPv6 specification [ID-DSMIP6].

   o  IPv4 Home Address Option defined in section 3.1.1 of [ID-DSMIP6].
      This option MUST be present in the Proxy Binding Update message
      sent by the mobile access gateway to the local mobility anchor,
      when requesting IPv4 home address support.

   o  IPv4 Address Acknowledgment Option defined in section 3.2.1 of
      [ID-DSMIP6].  This option MUST be present in the Proxy Binding
      Acknowledgment, if the local mobility anchor accepts IPv4 home
      address support.

3.4.  Mobile Access Gateway Operation

   o  All the considerations as explained in Section 6.11 of the base
      Proxy Mobile IPv6 specification apply here.

   o  When a mobile node attached to an access link and attempts to
      obtain an IPv4 address configuration, using DHCP or other
      procedures, it will get an IPv4 address as a IPv4 home address
      from its home network prefix as discussed in Section 3.1.  The
      mobile access gateway on the access link where mobile node is
      attached, will register this address with the local mobility
      anchor using the IPv4 Home Address option, defined in Section
      3.1.1 of [ID-DSMIP6].  The IPv4 Home Address option is sent with a
      proxy binding update as shown in Figure 4. 3.  The proxy binding
      update MUST be protected by IPsec ESP.  How to build the IPv4 home
      address option is varied as follows:

      *  If a mobile access gateway needs to request dynamic IPv4 home
         address allocation to the local mobility anchor, it MUST set
         0.0.0.0 in the the IPv4 Home Address field of the IPv4 home
         address option as described in [ID-DSMIP] and send this option
         by the proxy binding update.

      *  If a mobile access gateway knows the IPv4 home prefix (or home
         address) for the mobile node from static mobile node's policy
         profile or DHCP server, it MUST set the known IPv4 home prefix
         to the IPv4 Home Address field and the Pref field of the IPv4
         home address option.  This option is carried by a proxy binding
         update described in Proxy Mobile IPv6 specification [ID-PMIP6].

               IPv6 header (src=PCoA, dst=LMAA)
                    Mobility header
                        -BU /*P flag is set*/
                       Mobility Options
                          -HNP* /*IPv6 home address*/
                          -TSO*
                          -IPv4-HAO

         *HNP: Home Network Prefix Option
         *TSO: Time Stamp Option

         Figure 4: 3: Proxy Binding Update for IPv4 Home Address Support

   o  When a mobile node gets IPv4 home address from Local Mobility
      Anchor through DHCP interaction with MAG that supports DHCP server
      functionality, the DHCP client in the mobile node recognizes MAG's
      IP address as DHCP server's IP address.  Thus, the DHCP client
      unicasts DHCP renew to the MAG, when the DHCP client goes into the
      DHCP RENEWING state [RFC2131].  However, when the mobile node
      handovers to a new MAG, the mobile node does not know the link
      change and the DHCP client would unicast DHCP request to the
      previous MAG whose IP address was acquired from DHCP offer.  So,
      DHCP client in the mobile node needs to reconfigure its local
      configuration parameters.  Therefore, MAG SHOULD discard any DHCP
      request message that does not belong to the MAG itself, so that
      the mobile node should go into the DHCP REBINDING state and
      broadcast DHCP request without server identifier.

   o  A proxy binding acknowledgment will be returned by the local
      mobility anchor.  In the proxy binding acknowledgment, an IPv4
      address acknowledgment option MUST be presented in reply to the
      IPv4 home address option.  The processing of this IPv4 home
      acknowledgment option is found in DSMIP6 specification [ID-
      DSMIP6].

   o  After receiving a Proxy Binding Acknowledgment message with the
      IPv4 Address Acknowledgment Option and if the status code in the
      Binding Acknowledgment and Status field in the IPv4 Address
      Acknowledgment values are set to Success, the mobile access
      gateway MUST setup a tunnel to the local mobility anchor and must
      also add a default route over the tunnel for all the mobile node's
      IPv4 traffic.  The encapsulation modes for the bi-directional
      tunnel may be as specified in Section 5.3 of Proxy Mobile IPv6
      specification [ID-PMIP6] and as in this specification.

   o  If the Status field in the IPv4 Address Acknowledgment Option
      indicates the rejection of the IPv4 home address mobility service,
      the mobile access gateway MUST not enable IPv4 routing for the
      mobile node's IPv4 traffic.

3.5.  Local Mobility Anchor Operation

   o  Upon receiving a Proxy Binding Update message with the IPv4 Home
      Address Option, defined in Section 3.1.1 of DSMIP6 specification
      [ID-DSMIP6], the local mobility anchor, if it determines that the
      mobile node is configured for IPv4 home address mobility service,
      the local mobility anchor MUST send the Proxy Binding
      Acknowledgment message with the IPv4 Address Acknowledgment
      Option, defined in Section 3.2.1 of DSMIP6 specification.  How to
      process the IPv4 home address option and how to return the IPv4
      address acknowledgment are described in [ID-DSMIP6].

                 IPv6 header (src=PCoA, dst=LMAA)
                    Mobility header
                        -BA /*P flag is set*/
                       Mobility Options
                          -HNP* /*IPv6 home address*/
                          -TSO*
                          -IPv4-ACK
                          -IPv4-DRA
         *HNP: Home Network Prefix Option
         *TSO: Time Stamp Option

        Figure 5: 4: Proxy Binding Acknowledgement for IPv4 Home Address
                                   Support

   o  After accepting the registration for the mobile node's IPv4 home
      address, the local mobility anchor will add an IPv4 host route
      over the tunnel to the mobile access gateway.  Any IPv4 packets
      that the local mobility anchor receives from a correspondent node
      will be tunneled to the mobile access gateway over the bi-
      directional tunnel, and then routed accordingly after removing the
      tunnel header.  The encapsulation modes for the bi-directional
      tunnel may be as specified in Section 5.3 of Proxy Mobile IPv6
      specification [ID-PMIP6] and as in this specification.

4.  IPv4 Transport Support

   As per the Proxy Mobile IPv6 specification [ID-PMIP6], the transport
   network between the local mobility anchor and the mobile access
   gateway is an IPv6 network.  This specification defines extensions
   for supporting the scenario where the local mobility anchor and the
   mobile access gateway may be separated by an IPv4 transport network
   and further these entities may be configured with IPv4 private
   addresses and with NAT translation devices in the path.

   When the network between the local mobility anchor and the mobile
   access gateway is an IPv4 network, the mobile access gateway can
   potentially register an IPv4 address with the local mobility anchor,
   as the care-of address in the mobile node's binding cache entry and
   thus creating an IPv4 tunnel for carrying all the mobile node's
   traffic.

   The DSMIPv6 specification [ID-DSMIP6] defines a solution for allowing
   a mobile node to roam over an IPv4 network and the same solution can
   be extended to Proxy Mobile IPv6.  As explained in Section 4.1, of
   the DSMIPv6 specification, a mobile access gateway can encapsulate a
   Proxy Binding Update IPv6 message in an IPv4-UDP packet and route it
   to the local mobility anchor.  The processing logic and the on path
   NAT detection logic is just as described in Section 4.3.  The
   signaling messages will always be IPv6 messages encapsulated in an
   IPv4 packet and carried as an IPv4 packet.  The data traffic to and
   from the mobile node will also be encapsulated and carried as IPv4
   packets.  This specification does not cover the dynamic discovery of
   the IPv4 address of the local mobility anchor (IPv4-LMAA) and thus it
   is assumed that the mobile access gateway can learn this address from
   the mobile node's policy profile or it can obtain this information
   through other techniques that are beyond the scope of this document.

4.1.  Mobility Options

   For supporting IPv4 transport support, the following options are
   required from the DSMIP6 specification [ID-DSMIP6].

   o  NAT detection Option, defined in section 3.2.2 of the DSMIP
      specification [ID-DSMIP6].  This option MUST be present in the
      Proxy Binding Acknowledgment when the local mobility anchor
      detects NAT in the path between mobile access gateway and itself.

4.2.  Extensions to Conceptual Data Structure

   There are certain extensions defined in DSMIP6 specification [ID-
   DSMIP6] for supporting this feature.

4.3.  NAT Detection

   The NAT detection logic in Proxy Mobile IPv6 is just as specified in
   DSMIP6 specification.

   When the transport network between the local mobility anchor and the
   mobile access gateway is an IPv4 network, the mobile access gateway
   must send Proxy Binding Update message encapsulated in an IPv4-UDP
   packet.  On receiving this Proxy Binding Update packet encapsulated
   in an IPv4-UDP packet, the local mobility anchor if it detects a NAT
   on the path, will send the Proxy Binding Acknowledgment message with
   the NAT Detection Option.  The presence of this option in the Proxy
   Binding Acknowledgment is an indication to the mobile access gateway
   about the presence of NAT in the path.  On detecting the NAT in the
   path, both the local mobility anchor and the mobile access gateway
   will set the encapsulation mode of the tunnel to IPv4-UDP.  The
   specific details around the NAT detection and the related logic is
   described in in Dual Stack for Mobile IPv6 specification [ID-DSMIP6].

4.4.  Mobile Access Gateway Operation

   o  All the considerations as explained in Section 6.11 of the base
      Proxy Mobile IPv6 specification apply here.

   o  If IPv4 transport support is enabled in order to place a mobile
      access gateway at IPv4 only network, the mobile access gateway
      MUST have an IPv4 address at the visiting network.  In addition to
      that, the mobile access gateway MUST also obtain IPv6 address
      configured for the Proxy Mobile IPv6 operation.  Even if the
      mobile access gateway does not have connectivity to the IPv6
      network, it MUST configure with an IPv6 address for sending the
      proxy binding registration to the local mobility anchor.

   o  As explained in Section 4.1, of the DSMIPv6 specification, the
      mobile access gateway can encapsulate a Proxy Binding Update
      message and carry it in IPv4 and UDP packet.  The processing logic
      for handling the NAT detection at the mobile node is applicable to
      the mobile access gateway as described in Section 4.3.  An example
      of proxy binding update sent by mobile access gateway is shown in
      Figure 6. 5.  Note that the source address of the inner IPv6 header
      MUST set to the IPv6 address assigned to the mobile access gateway
      and the destination address MUST be the local mobility anchor's
      IPv6 address (LMAA).  The source address of the outer packet MUST
      be the IPv4-proxy-CoA and the destination MUST be the local
      mobility anchor's IPv4 address (IPv4-LMAA).  For the NAT handling,
      UDP header MUST be always used for the proxy binding update.  The
      UDP port number is defined in [ID-DSMIP6].  The proxy binding
      update MUST be protected by IPsec ESP.  The security association
      for IPv4 addresses of the mobile access gateway and local mobility
      anchor are pre-established.

                 IPv4 header (src=IPv4-proxy-CoA, dst=IPv4-LMAA)
                    UDP header
                      IPv6 header (src=v6MAG*, dst=LMAA)
                         Mobility header
                             -BU /*P flag is set*/
                            Mobility Options
                               -HNP* /*IPv6 home address*/
                               -TSO*
                               -IPv4-HAO /*if IPv4 HoA is required*/
                               -NAI /* NAI Option */

         *HNP: Home Network Prefix Option
         *TSO: Time Stamp Option
         *v6MAG: IPv6 address assigned to the mobile access gateway.
         *NAI: NAI Option

      Figure 6: 5: Proxy Binding Update from mobile access gateway in IPv4
                                   network

   o  After receiving a Proxy Binding Acknowledgment message
      encapsulated in an IPv4 packet, the mobile access gateway MUST
      verify the Proxy Binding Acknowledgment according to the Section
      4.3 of DSMIP6 specification [ID-DSMIP6].

   o  If the Status field indicates Success, the mobile access gateway
      MUST setup a tunnel to the local mobility anchor and add a default
      route over the tunnel for all the mobile node's IPv6 traffic.  If
      the NAT is available and the NAT detection option is presented in
      the Proxy Binding Acknowledgment, the mobile access gateway MUST
      use UDP tunnel to traverse the NAT and MUST send a proxy binding
      update every refresh time specified in the NAT detection option.
      The detailed operation can be found in DSMIP6 specification [ID-
      DSMIP6].

   o  If the Status field in the proxy binding acknowledgment indicates
      the rejection of the binding registration, the mobile access
      gateway MUST not enable IPv4 transport for the mobile node's
      traffic.

   o  On receiving any packets from the mobile node's IPv6 home address
      and/or IPv4 home address, the mobile access gateway tunnels the
      packets to local mobility anchor as shown in Figure 7 6
               IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
                   UDP header /*Only if NAT is detected*/
                       union { /*following either v6 or v4 header */
                           IPv4 header (src=MN's IPv4-HoA, dst=IPv4 CN)
                           IPv6 header (src=MN's IPv6-HoA, dst=IPv6 CN)
                       }
                               Upper layer protocols /*TCP,UDP,SCTP*/

                  Figure 7: 6: Tunneled Packets from MAG to LMA

4.5.  Local Mobility Anchor Operation

   When a mobile node is attached to a mobile access gateway that is
   reachable only through an IPv4 transport network, the local mobility
   anchor must establish an IPv4 tunnel for routing the mobile node's
   IPv4 and IPv6 home address traffic.  The DSMIPv6 specification
   provides the semantics on how the IPv4 tunnel needs to be negotiated
   and the detection logic of the NAT devices.  This specification
   leverages the NAT Detection Option, defined in the DSMIP6
   specification for the use in Binding Acknowledgment message and
   extends it to Proxy Binding Acknowledgment messages.  The operational
   steps are defined below.

   o  Upon receiving a Proxy Binding Update message encapsulated in an
      IPv4 packet, the local mobility anchor MUST send the Proxy Binding
      Acknowledgment to the mobile access gateway's IPv4-Proxy-CoA by
      using IPv4 encapsulation.  If the NAT is detected, the NAT
      detection option MUST be used in the Proxy Binding Acknowledgment.
      How to detect NAT is described in Section 4.1 of [ID-DSMIP6] and
      Section 4.3.

   o  An example of proxy binding acknowledgment sent by local mobility
      anchor is shown below.  The same illustration for Mobile IPv6 can
      be found in Section 4.1 of [ID-DSMIP6].  The proxy binding
      acknowledgment MUST be protected by IPsec ESP.  The security
      association for IPv4 addresses of the mobile access gateway and
      local mobility anchor are pre-established.

              IPv4 header (src=IPv4-LMAA, dst=IPv4-proxy-CoA)
                  UDP header /*Only if NAT is detected*/
                   IPv6 header (src=LMAA, dst=v6MAG)
                      Mobility header
                          -BA /*P flag is set */
                         Mobility Options
                            -HNP* /* IPv6-MN-HoA */
                            -TSO*
                            -IPv4-ACK /* Only if IPv4 HoA is required */
                            -NAT-DET /* Only if NAT is detected */
                            -NAI /*NAI Option */

      *HNP: Home Network Prefix Option
      *TSO: Time Stamp Option
      *v6MAG:  IPv6 address assigned to the mobile access gateway.

            Figure 8: 7: Proxy Binding Acknowledgment in IPv4 network

   o  After accepting the registration from the mobile access gateway
      locating at the IPv4 only network, the local mobility anchor MUST
      setup a tunnel to the mobile access gateway.  The tunnel is
      established between the v4-LMAA and the IPv4-Proxy-CoA of the
      mobile access gateway.  If the NAT is available and the NAT
      detection option is included in the Proxy Binding Acknowledgment,
      the local mobility anchor MUST use UDP encapsulation for the
      tunnel.  The local mobility anchor also setup a host routes for
      the IPv4 home address and the IPv6 home address of the mobile node
      over the tunnel to the mobile access gateway.  Any traffic that
      the local mobility anchor receives from a correspondent node will
      be tunneled to the mobile access gateway over the bi-directional
      tunnel and then routed accordingly after removing the tunnel
      headers.  The encapsulation modes for the bi-directional tunnel
      may be as specified in Section 5.3 of Proxy Mobile IPv6
      specification [ID-PMIP6] and as in this specification.

   o  When sending any packets meant to a mobile node's IPv4 home
      address or IPv6 home address, the local mobility anchor tunnels
      the packet to mobile access gateway as shown in Figure 9 8

               IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA)
                   UDP header /*Only if NAT is detected*/
                       union { /*following either v6 or v4 header */
                           IPv4 header (src=IPv4-CN, dst=IPv4-HoA)
                           IPv6 header (src=IPv6-CN, dst=IPv6-HoA)
                       }
                               Upper layer protocols /*TCP,UDP,SCTP*/
                  Figure 9: 8: Tunneled Packets from LMA to MAG

4.6.  Tunnel Management

   As specified in the Proxy Mobile IPv6 specification, the bi-
   directional tunnel between the local mobility anchor and the mobile
   access gateway, is a shared tunnel and all the considerations from
   Section 6.6 of Proxy Mobile IPv6 [ID-PMIP6] apply for IPv4 transport
   as well.

5.  IANA Considerations

   This document does not define any new messages.  The UDP port number
   for proxy binding update and acknowledgment will be defined in [ID-
   DSMIP6].

6.  Security Considerations

   This specification describes the use of IPv4 transport network
   between the local mobility anchor and the mobile access gateway.  All
   the signaling messages exchanged between the mobile access gateway
   and the local mobility anchor over the IPv4 transport MUST be
   protected using IPsec, just as the messages must be protected when
   using IPv6 transport and as specified in the Section 4.0, of the
   Proxy Mobile IPv6 specification [ID-PMIP6].

   When supporting IPv4 address assignment from a DHCP server, all the
   IPv4 home addresses managed in the DHCP server must be reachable via
   local mobility anchor MUST be the prefix owner and the topological so that local mobility anchor
   point intercepts
   packets meant for the an IPv4 home address pools that are configured on and tunnels them to the mobile
   node via corresponding mobile access gateway.  Moreover, all the DHCP server
   for allocation for
   messages between a DHCP relay and the mobile nodes. DHCP server SHOULD be securely
   exchanged.

   After receiving a Proxy Binding Update message with an IPv4 Home
   Address Option, the local mobility anchor MUST be able to verify that
   the mobile node is authorized to use that address before setting up
   forwarding for that host route.

   When supporting dynamic IPv4 address assignment by DHCP and also from
   local mobility anchor, it should be ensured both the entities are
   configured with different address pools, so as to avoid both entities
   do not allocate the same address to different mobile nodes.

7.  Contributors

   This document reflects discussions and contributions from several
   people (in alphabetical order):

   Kuntal Chowdhury

      kchowdhury@starentnetworks.com

   Vijay Devarapalli

      vijay.devarapalli@azairenet.com

   Sangjin Jeong

      sjjeong@gmail.com

      sjjeong@etri.re.kr

   Basavaraj Patil

      basavaraj.patil@nsn.com

   Myungki Shin

      myungki.shin@gmail.com

8.  Acknowledgments

   The IPv4 support for Proxy Mobile IPv6 was initially covered in the
   internet-draft [draft-sgundave-mip6-proxymip6-02.txt].  This document
   leverages lot of text from that document.  We would like to thank all
   the authors of the document and acknowledge that initial work.

9.  References

9.1.  Normative References

   [RFC-1332] McGregor, G., "The PPP Internet Protocol Control Protocol
   (IPCP)", RFC 1332, May 1992.

   [RFC-1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD
   51, RFC 1661, July 1994.

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

   [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
   2131, March 1997.

   [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
   IPv6 Specification", RFC 2473, December 1998.

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

   [RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
   Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents",
   RFC 3776, June 2004.

   [RFC-4830] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta,
   G., Liebsch, M., "Problem Statement for Network-based Localized
   Mobility Management", September 2006.

   [RFC-4831] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta,
   G., Liebsch, M., "Goals for Network-based Localized Mobility
   Management", October 2006.

   [RFC-4832] Vogt, C., Kempf, J., "Security Threats to Network-Based
   Localized Mobility Management", September 2006.

   [ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack
   Hosts and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-03.txt
   ,October 2006.

   [ID-MIP6-IKEV2] Devarapalli, V. and Dupont, F., "Mobile IPv6
   Operation with IKEv2 and the revised IPsec Architecture",
   draft-ietf-mip6-ikev2-ipsec-08.txt, December 2006.

   [ID-PMIP6] Gundavelli, S., et.al, "Proxy Mobile IPv6",
   draft-sgundave-mip6-proxymip6-02.txt, March
   draft-ietf-netlmm-proxymip6-01.txt, December 2007.

9.2.  Informative References

   [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
   (IPv6) Specification", RFC 2460, December 1998.

   [RFC-2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
   Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.

   [RFC-2462] Thompson, S., Narten, T., "IPv6 Stateless Address
   Autoconfiguration", RFC 2462, December 1998.

   [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
   M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
   RFC 3315, July 2003.

   [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the
   Internet Protocol", RFC 4301, December 2005.

   [RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC
   4303, December 2005.

   [RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2)
   Protocol", RFC 4306, December 2005.

   [ID-DSMIP6-PS] Tsirtsis, G., et.al, "Problem Statement: Dual Stack
   Mobility", draft-ietf-mip6-dsmip-problem-03.txt, January 2007.

Authors' Addresses

   Ryuji Wakikawa
   Keio University
   Department of Environmental Information, Keio University.
   5322 Endo
   Fujisawa, Kanagawa  252-8520
   Japan

   Email: ryuji@sfc.wide.ad.jp

   Sri Gundavelli
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: sgundave@cisco.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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, THE IETF TRUST 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.

Intellectual Property

   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.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).