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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 RFC 5844

NETLMM Working Group                                R. Wakikawa (Editor)
Internet-Draft                                           Keio University
Intended status: Standards Track                           S. Gundavelli
Expires: May 22, 2008                                              Cisco
                                                       November 19, 2007


                   IPv4 Support for Proxy Mobile IPv6
              draft-ietf-netlmm-pmip6-ipv4-support-02.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 May 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).













Wakikawa (Editor) & Gundavelli  Expires May 22, 2008            [Page 1]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


Abstract

   This document specifies extensions to Proxy Mobile IPv6 protocol for
   supporting IPv4 protocol.  The scope of this IPv4 support includes
   the support for the mobile node's IPv4 home address mobility and for
   allowing the mobility entities in the Proxy Mobile IPv6 domain to
   exchange signaling messages over IPv4 transport.  The solution
   leverages the extensions defined in DSMIPv6 specification 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.  Mobile Access Gateway Considerations . . . . . . . . . . . 10
       3.2.1.  Extensions to Binding Update List Entry  . . . . . . . 10
       3.2.2.  Signaling Considerations . . . . . . . . . . . . . . . 10
     3.3.  Local Mobility Anchor Considerations . . . . . . . . . . . 14
       3.3.1.  Extensions to Binding Cache Entry  . . . . . . . . . . 14
       3.3.2.  Signaling Considerations . . . . . . . . . . . . . . . 15
       3.3.3.  Routing Considerations . . . . . . . . . . . . . . . . 17

   4.  IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 19
     4.1.  NAT Detection  . . . . . . . . . . . . . . . . . . . . . . 20
     4.2.  Mobile Access Gateway Considerations . . . . . . . . . . . 20
       4.2.1.  Extensions to Binding Update List Entry  . . . . . . . 20
       4.2.2.  Signaling Considerations . . . . . . . . . . . . . . . 20
     4.3.  Local Mobility Anchor Considerations . . . . . . . . . . . 24
       4.3.1.  Extensions to Binding Cache Entry  . . . . . . . . . . 24
       4.3.2.  Signaling Considerations . . . . . . . . . . . . . . . 24
     4.4.  Tunnel Management  . . . . . . . . . . . . . . . . . . . . 26

   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27

   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28

   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29

   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 29

   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29



Wakikawa (Editor) & Gundavelli  Expires May 22, 2008            [Page 2]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 29
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 30

   Appendix A.  DHCP usages for IPv4 home address assignment  . . . . 31

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
   Intellectual Property and Copyright Statements . . . . . . . . . . 34












































Wakikawa (Editor) & Gundavelli  Expires May 22, 2008            [Page 3]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


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 network infrastructure.  Thus, it is reasonable to assume that a
   mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only
   IPv6-only or in dual-stack mode and additionally the network between
   the mobile access gateway and a local mobility anchor may be an IPv4-
   only network.  It is also reasonable to expect the same mobility
   infrastructure in a Proxy Mobile IPv6 domain to provide mobility to
   the mobile node's operating in IPv4, IPv6 or in dual mode and when
   the network between the local mobility anchor and the mobile access
   gateway is an IPv4 network.  The motivation and scope of IPv4 support
   in Mobile IPv6 is summarized in [RFC-4977].

   The Proxy Mobile IPv6 protocol[ID-PMIP6] specifies a mechanism for
   providing IPv6 home address mobility support to a mobile node in a
   Proxy Mobile IPv6 domain and when there is an IPv6 transport network
   separating the entities involved in the mobility management.  The
   extensions defined in this document are for extending IPv4 support to
   the Proxy Mobile IPv6 protocol [ID-PMIP6].

   The scope of IPv4 support in Proxy Mobile IPv6 includes the support
   for the following two features:

   o  IPv4 Home Address Mobility Support: A mobile node that has IPv4
      stack enabled will be able to obtain an IPv4 address and be able
      to use that address from any of the access networks in that Proxy
      Mobile IPv6 domain.  The mobile node is not required to be
      allocated or assigned an IPv6 address for enabling IPv4 home
      address support.

   o  IPv4 Transport Support: The mobility entities in the Proxy Mobile
      IPv6 domain will be able to exchange Proxy Mobile IPv6 signaling
      messages over an IPv4 transport and further the local mobility
      anchor or the mobile access gateway may be using IPv4 private
      addresses and with NAT [RFC-3022] translation devices separating
      them.

   The DSMIPv6 specification [ID-DSMIP6], defines IPv4 home address
   mobility and IPv4 transport support to the Mobile IPv6 protocol [RFC-
   3775].  The solution specified in this document leverages these
   extensions for enabling IPv4 support to Proxy Mobile IPv6 protocol.
   These two features, the IPv4 Home Address Mobility support and IPv4
   transport support features, are independent of each other and
   deployments can choose to enable any one or both of these features.

   This specification requires that the local mobility anchor and the



Wakikawa (Editor) & Gundavelli  Expires May 22, 2008            [Page 4]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


   mobile access gateway are both IPv6 capable and IPv6 enabled,
   irrespective of the type of transport network (IPv4 or IPv6),
   connecting these two entities.  The signaling protocol is
   fundamentally based on Mobile IPv6.

   Figure 1 illustrates a Proxy Mobile IPv6 domain supporting IPv4 home
   address mobility and IPv4 transport support 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 [RFC-3022] 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









Wakikawa (Editor) & Gundavelli  Expires May 22, 2008            [Page 5]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


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 [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], Dual
   Stack Mobile IPv6 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 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.  This address
      will be used as the source address for the signaling messages sent
      by the mobile access gateway to the local mobility anchor and will
      be the registered Care-of address in the mobile node's Binding
      Cache entry.  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 that
      flow.

   IPv4 Local Mobility Anchor Address (IPv4-LMAA)

      The IPv4 address that is configured on the interface of a local
      mobility anchor and is the transport endpoint of the tunnel
      between the local mobility anchor and the mobile access gateway.
      This is the address to where the mobile access gateway sends the
      Proxy Binding Update messages.  If the local mobility anchor is
      configured to be behind a NAT device, this address will be the
      address allocated by the NAT device for that flow.












Wakikawa (Editor) & Gundavelli  Expires May 22, 2008            [Page 6]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


3.  IPv4 Home Address Mobility Support

   An IPv4 enabled mobile node when it attaches to the Proxy Mobile IPv6
   domain, the network will ensure the mobile node will be able to
   obtain an IPv4 address (IPv4-MN-HoA) from its home network prefix for
   the interface attached to the access network in that Proxy Mobile
   IPv6 domain.  Using the extensions defined in this specification, the
   mobile access gateway on the access network will exchange the
   signaling messages with the mobile node's local mobility anchor and
   will setup the required routing state for that home address.

   If the mobile node connects to the Proxy Mobile IPv6 domain, through
   multiple interfaces and simultaneously through different access
   networks, each of the connected interfaces will obtain an address
   from a unique IPv4 home network prefix.  In such configuration, there
   will be multiple Binding Cache entries on the local mobility anchor
   for that mobile node and with one entry for each connected interface,
   as specified in Section 5.4 [ID-PMIP6].

   The support for IPv4 addressing is orthogonal to the IPv6 addressing
   support.  Unlike as specified in [ID-DSMIP6], the mobile node is not
   required to have an IPv6 home address for obtaining IPv4 home address
   mobility.  A mobile node attached to an access link in a Proxy Mobile
   IPv6 domain will be able to obtain just an IPv4 address configuration
   or both IPv4 and IPv6 address configurations on the connected
   interface.  The policy on the mobile access gateway will determine if
   the mobile node is entitled for both the protocols or a single
   protocol and based on what is enabled, only those protocols will be
   enabled on the access link.  Further, when the mobile node after
   obtaining the IPv4 or IPv4/IPv6 address configuration on the access
   link, performs an inter-technology handoff, the network will ensure
   the mobile node will be able to use the same IPv4/IPv6 address
   configuration on the new interface.

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 [RFC-2131], IPCP or
   IKEv2 that are supported on that access link, will be able to obtain
   required information for its IPv4 home address configuration.  The
   required information includes the IPv4 home address, the IPv4 home
   network prefix and IPv4 home network prefix length.  Any available
   IPv4 address configuration mechanisms can be used such as static
   configuration method specific to the access link or dynamic
   configuration from DHCP.




Wakikawa (Editor) & Gundavelli  Expires May 22, 2008            [Page 7]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


   When a mobile node is configured with a static IPv4 home address, the
   IPv4 home address information SHOULD be stored in the mobile node's
   policy profile.  The mobile access gateway where the mobile node
   attached obtains the static IPv4 home address from the policy
   profile.  The mobile access gateway MUST set 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].

   On the other hand, if DHCP is used for the IPv4 home address
   allocation as specified in [RFC-2131], a DHCP server and/or a DHCP
   relay agent on the link will ensure the mobile node is assigned an
   address from its home network prefix.  There are several
   configurations where the DHCP entities are located in a Proxy Mobile
   IPv6 domain.  This document recommends following two configurations
   as default operations.  The other configurations are explained in
   Appendix A.

   1.  DHCP server is co-located with each mobile access gateway

   2.  DHCP server is co-located with a local mobility anchor and a DHCP
       relay is co-located with each mobile access gateway

   Figure 2 shows the operational sequence of the home address
   assignment when a DHCP server is co-located with each mobile access
   gateway.  In this scenario, a DHCP server (i.e. mobile access
   gateway) interacts with a DHCP client on a mobile node, while a local
   mobility anchor actually provides an IPv4 Home Address dynamically to
   a mobile node during proxy binding registration.  All mobile access
   gateways SHOULD support minimal functionality of a DHCP server in
   order to send DHCP offer and acknowledgment messages to the mobile
   node in reply to the DHCP discovery and request messages.  The mobile
   access gateway is seen as a DHCP 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 (set 0.0.0.0 in
   the the IPv4 Home Address field of the IPv4 home address option as
   described in [ID-DSMIP6]).  The mobile access gateway MUST return its
   own IP address in the 'server identifier' option when sending DHCP
   offer message to the mobile node.  Thus, whenever the mobile node
   changes the attached mobile access gateway, this server identifier
   must be updated.  The detail can be found in Section 3.2.2.  Any
   information carried in DHCP options such as addresses of domain name
   server, time server, lpr server, etc.  MUST be configured in all the
   mobile access gateway (i.e.  DHCP server) if necessary.







Wakikawa (Editor) & Gundavelli  Expires May 22, 2008            [Page 8]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


     MN   MAG(DHCP-S)  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.


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

   In the second scenario, a DHCP relay is co-located at each mobile
   access gateway and a DHCP server is co-located at a local mobility
   anchor.  The mobile access gateway learns the IPv4 home address from
   the DHCP reply and sends that information to the mobile node by DHCP
   offer message.  Meanwhile, it notifies the assigned IPv4 home address
   by an IPv4 home address option in a proxy binding update to the local
   mobility anchor.  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.  In addition, the DHCP
   messages MAY be sent across an administrative boundaries.  The
   operators MUST ensure to secure these messages.  More remarks can be
   found in Section 6.  Figure 3 are the sequence of IPv4 home address
   assignment using DHCP Relay.


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


                      Figure 3: The use of DHCP relay




Wakikawa (Editor) & Gundavelli  Expires May 22, 2008            [Page 9]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


3.2.  Mobile Access Gateway Considerations

3.2.1.  Extensions to Binding Update List Entry

   For supporting this feature, the conceptual Binding Update List entry
   data structure needs to be extended with the following additional
   parameter, as specified in [ID-DSMIP6] specification and are
   presented here for convenience.

   o  The IPv4 home address of the attached mobile node.  The IPv4 home
      address value is acquired from the mobile node's local mobility
      anchor through the received Proxy Binding Acknowledgment messages.

3.2.2.  Signaling Considerations

   All the considerations explained in Section 6.11 of the base Proxy
   Mobile IPv6 specification apply here.  For supporting IPv4 home
   address mobility feature, the following additional considerations
   MUST be applied.


   Mobile Node Attachment and Initial Binding Registration:

   o  After detecting a new mobile node on its access link, the mobile
      access gateway must identify the mobile node and acquire its MN-
      Identifier.  If it determines that the IPv4 home address mobility
      service needs to be offered to the mobile node, it MUST send a
      Proxy Binding Update message to the local mobility anchor.  The
      message MUST include the IPv4 Home Address option, defined in
      section 3.1.1 of [ID-DSMIP6].  The mobile access gateway MAY also
      include the IPv6 Home Network Prefix option in the same message
      for requesting IPv6 home address support in addition to IPv4 home
      address support for the mobile node.

   o  If the mobile access gateway learns the mobile node's IPv4 home
      network prefix or the IPv4 home address either from its policy
      store or from the DHCP messages exchanged between the mobile node
      and the DHCP server, the mobile access gateway can specify the
      same in the IPv4 Home Address option for requesting the local
      mobility anchor to allocate that address or to allocate an address
      from the specified home network prefix.  If the specified value is
      0.0.0.0, then the local mobility anchor will consider this as a
      request for dynamic address allocation.

   o  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



Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 10]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


      proxy binding update as shown in Figure 4.  The format of the
      proxy binding update is slightly different from the one of [ID-
      DSMIP6].  In [ID-DSMIP6], the source address of IPv6 header must
      be a home address of the mobile terminal.  However, since Proxy
      Mobile IPv6 supports only IPv4 capable node, IPv6 home address is
      not always available on the terminal.  In addition to this, the
      originator of this proxy binding update is not the mobile
      terminal, but the mobile access gateway.  The mobile access
      gateway cannot send the proxy binding update with the mobile
      node's home address because of security reasons (IPsec and ingress
      filtering).  Therefore, in this specification, the mobile access
      gateway's care-of address (Proxy-CoA) is used in the IPv6 source
      address field.

   o  The proxy binding update MUST be protected by IPsec ESP.


   Receiving Binding Registration Reply:

   o  If the received Proxy Binding Acknowledgement message has neither
      an IPv4 Address Acknowledgement option or a Home Network Prefix
      option present, the mobile access gateway MUST ignore the Proxy
      Binding Acknowledgement and MUST NOT enable routing for the mobile
      node's IPv4 Home Address or IPv6 home address traffic.  However,
      if there is an IPv4 Home Address Acknowledgment option present in
      the reply, the option MUST be processed as per the rules specified
      in Dual Stack Mobile IPv6 specification [ID-DSMIP6].

   o  If the received Proxy Binding Acknowledgement message has the
      Status field value in the IPv4 Address Acknowledgement Option set
      to a value that indicates that the request was rejected by the
      local mobility anchor, the mobile access gateway MUST NOT enable
      IPv4 support for the mobile node.  However, if there is an IPv6
      Home Network Prefix option in the Proxy Binding Acknowledgement
      message and the Status field in the message is set to a value 0
      (Proxy Binding Update accepted), the mobile access gateway MUST
      enable IPv6 support for the mobile node.

   o  If the received Proxy Binding Acknowledgement message has the
      Status field value set to 0 (Proxy Binding Update accepted), the
      mobile access gateway MUST update a Binding Update List entry and
      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 mode for the bi-directional tunnel set
      to IPv4-In-IPv6 mode.  The considerations from Section 6.10 [ID-
      PMIP6] apply.





Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 11]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


   Extending Binding Lifetime:

   o  For extending the binding lifetime of a currently registered
      mobile node , the mobile access gateway MUST send a Proxy Binding
      Update message to the local mobility anchor with a non zero
      lifetime value.  The message MUST contain the IPv4 Home Address
      option with the value set to the currently registered IPv4 home
      address value.  Additionally, if there is a registered IPv6 home
      network prefix for the mobile node for the connected interface on
      that access link, both the options, Home Network Prefix option and
      the IPv4 Home Address option MUST be present and with the values
      set to the respective registered values.


   Mobile Node Detachment and Binding De-Registration:

   o  As specified in Section 6.9.1 [ID-PMIP6], at any point in time,
      when the mobile access gateway detects that the mobile node has
      moved away from its access link, it SHOULD send a Proxy Binding
      Update message to the local mobility anchor with the lifetime
      value set to zero.  The message MUST contain the IPv4 Home Address
      option with the value set to the currently registered IPv4 home
      address value.  Additionally, if there is a registered IPv6 home
      network prefix for the mobile node for the connected interface on
      that access link, both the options, Home Network Prefix option and
      the IPv4 Home Address option MUST be present and with the values
      set to the respective registered values.


   Constructing the Proxy Binding Update Message:

   o  The mobile access gateway when sending the Proxy Binding Update
      request to the local mobility anchor for requesting IPv4 home
      address mobility support MUST construct the message as specified
      below.


               IPv6 header (src=Proxy-CoA, dst=LMAA)
                    Mobility header
                        -BU /*P & A flags are set*/
                       Mobility Options
                          - Timestamp Option (optional)
                          - Mobile Node Identifier option
                          - Access Technology Type option (Mandatory)
                          - Mobile Node Interface Identifier option
                            (Optional)

                          - IPv4 Home Address option (Mandatory)



Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 12]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


         Figure 4: Proxy Binding Update for IPv4 Home Address Support

   o  The source address field of the IPv6 header MUST be the IPv6
      address of the mobile access gateway.

   o  The IPv4 Home Address option [ID-DSMIP6] MUST be present.  The
      address value MAY be set 0.0.0.0 or to a specific value.

   o  All the other fields and the options MUST be constructed, as
      specified in [ID-PMIP6].


   DHCP Messages from the mobile node:

   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 an 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

   o  When a mobile node obtains an IPv4 home address from DHCP server,
      the mobile access gateway SHOULD record the assigned IPv4 home
      address in the policy profile.  A new mobile access gateway can
      send a proxy binding update when a mobile node roams to the new
      mobile access gateway.

   o  When a mobile node first attaches to a Proxy Mobile IPv6 domain, a
      mobile access gateway triggers a proxy binding update by following
      conditions.  It is rarely happened that the DHCP procedure and
      proxy binding procedure run at the same time except for the
      initial attachment.

      *  When a mobile access gateway is a DHCP server, it MUST send a
         proxy binding update right after receiving a DHCP discovery
         message from a mobile node.  By sending the proxy binding
         update, it will learn the assigned IPv4 home address from the
         local mobility anchor.

      *  When a DHCP relay is co-located with a mobile access gateway,
         the mobile access gateway MUST send a proxy binding update as
         soon as it receives a DHCP Acknowledgement message from the
         DHCP server.  During the proxy binding registration, it MUST
         NOT relay the DHCP Acknowledgement message to the DHCP client.
         After the proxy binding is successfully registered, the DHCP



Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 13]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


         relay (i.e. mobile access gateway) MUST forward the DHCP
         Acknowledgement to the DHCP client (i.e. mobile node).  Before
         a DHCP Acknowledgement message, a DHCP client and the DHCP
         server do not complete the negotiation of IPv4 address
         assignment so that the mobile access gateway MAY send a
         different IPv4 address to the local mobility anchor by a proxy
         binding update.

   o  After the initial procedure described in above, DHCP runs
      independently to the proxy binding registration for renewing the
      assigned IPv4 home address.  It is not necessary to run DHCP
      whenever a mobile node changes its attached mobile access gateway.
      A DHCP client renew the address according to the address lifetime,
      etc.  However, whenever a mobile node renews the IPv4 home address
      by DHCP (DHCP RENEWING STATE [RFC-2131]), the mobile access
      gateway SHOULD send a proxy binding update to the local mobility
      anchor regardless of the mobile node's assigned address changes.

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

3.3.  Local Mobility Anchor Considerations

3.3.1.  Extensions to Binding Cache Entry

   For supporting this feature, the conceptual Binding Cache entry data
   structure needs to be extended with the following additional
   parameter, as specified in [ID-DSMIP6] specification and is presented
   here for convenience.

   o  The IPv4 home address of the registered mobile node.  The IPv4
      home address value may have been statically configured in the
      mobile node's policy profile, it MAY have been assigned by a DHCP
      server, or it MAY have been dynamically allocated by the local



Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 14]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


      mobility anchor.

3.3.2.  Signaling Considerations

   All the considerations explained in Section 5.3 [ID-PMIP6] apply
   here.  For supporting IPv4 home address mobility feature, the
   following additional considerations MUST be applied.


   Processing Binding Registrations:

   o  If there is an IPv4 Home Address option present in the request,
      but if there is no Home Network Prefix option present in the
      request, the local mobility anchor MUST NOT reject the request as
      specified in [ID-PMIP6].  At least one of these two options MUST
      be present.  However, if both the options are not present, the
      local mobility anchor MUST reject the request and send a Proxy
      Binding Acknowledgement message with Status field set to
      MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home
      network prefix option).

   o  The local mobility anchor MUST use the identifier from the Mobile
      Node Identifier Option [RFC-4283] present in the Proxy Binding
      Update request and MUST apply multihoming considerations specified
      in Section 5.4 [ID-PMIP6] and from this section for performing the
      Binding Cache entry existence test.

   o  If there is no existing Binding Cache entry that matches the
      request, the local mobility anchor MUST consider this request as
      an initial binding registration request.  If the entry exists, the
      local mobility anchor MUST consider this request as a binding re-
      registration request.

   o  The proxy care-of address MUST be retrieved from the source
      address field of the proxy binding update message.

   o  If the IPv4 Home Address option present in the Proxy Binding
      Update request has the value of 0.0.0.0, the local mobility anchor
      MUST allocate an IPv4 home address for the mobile node and send a
      Proxy Binding Acknowledgement message and including the IPv4
      Address Acknowledgement option, defined in Section 3.2.1 of [ID-
      DSMIP6], containing the allocated address value.  The specific
      details on how the local mobility anchor allocates the home
      address is outside the scope of this document.  The local mobility
      anchor MUST ensure the allocated prefix is not in use by any other
      mobile node.





Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 15]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


   o  If the local mobility anchor is unable to allocate an IPv4 home
      address for the mobile node, it MUST reject the request and send a
      Proxy Binding Acknowledgement message with Status field set to 130
      (Insufficient resources).

   o  Upon accepting the request, the local mobility anchor MUST create
      a Binding Cache entry for the mobile node.  It must set the fields
      in the Binding Cache entry to the accepted values for that
      binding.  It MUST also establish a bi-directional tunnel to the
      mobile access gateway, as described in [RFC-2473].  Considerations
      from Section 5.6 [ID-PMIP6] MUST be applied.  The local mobility
      anchor MUST add an IPv4 host route for that allocated IPv4 home
      address over the tunnel to the mobile access gateway.


   Multihoming Considerations:

   o  The multihoming considerations specified in Section 5.4 [ID-PMIP6]
      allows the local mobility anchor to perform the Binding Cache
      entry existence test for identifying the mobility session, by
      using the mobile node identifier, interface identifier and the
      Home Network Prefix values.  When using an IPv4 home address
      value, instead of the IPv6 home network prefix for matching the
      Binding Cache entry, all those considerations equally apply for
      the IPv4 home address as well.

   o  If there is an Home Network Prefix option present in the Proxy
      Binding Update request and with a NON_ZERO value, the local
      mobility anchor MUST use this parameter in combination with the
      mobile node identifier and interface identifier for matching the
      Binding Cache entry, just as specified in Section 5.4 [ID-PMIP6].
      For all other cases, the local mobility anchor MUST use the IPv4
      home address parameter in combination with the mobile node
      identifier and interface identifier for matching the Binding Cache
      entry, as specified in Section 5.4 [ID-PMIP6].


   Constructing the Proxy Binding Acknowledgement Message:

   o  The local mobility anchor when sending the Proxy Binding
      Acknowledgement message to the mobile access gateway MUST
      construct the message as specified below.









Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 16]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


            IPv6 header (src=LMAA, dst=Proxy-CoA)
                 Mobility header
                     -BA /*P flag is set*/
                    Mobility Options
                       - Timestamp option (optional)
                       - Mobile Node Identifier Option
                       - Access Technology Type option (Mandatory)
                       - Mobile Node Interface Identifier option
                            (Optional)

                       - IPv4 Address Acknowledgement Option (Mandatory)



        Figure 5: Proxy Binding Acknowledgement for IPv4 Home Address
                                   Support

   o  The destination address field of the IPv6 header MUST be set to
      the mobile access gateway.

   o  The IPv4 Address Acknowledgement option MUST be present in the
      Proxy Binding Acknowledgement message.  If both the IPv4 Home
      Address option and the IPv6 Home Network Prefix option were not
      present in the Proxy Binding Update request and if the Status
      field value in the message is set to
      MISSING_HOME_NETWORK_PREFIX_OPTION, the value MUST be set to
      ALL_ZERO.  For all other Status values, the IPv4 home address
      value MUST be set to the allocated address value for that mobile
      node.  Considerations from [ID-DSMIP6] MUST be applied on
      determining Status field value in the option.

   o  All the other fields and the options MUST be constructed, as
      specified in [ID-PMIP6].

3.3.3.  Routing Considerations

   Forwarding Considerations for the mobile node's IPv4 home address
   traffic.


   Intercepting Packets Sent to the Mobile Node's IPv4 home network:

   o  When the local mobility anchor is serving a mobile node, it MUST
      be able to receive packets that are sent to the mobile node's IPv4
      network.  In order for it to receive those packets, it MUST
      advertise a connected route in to the Routing Infrastructure for
      the mobile node's IPv4 home network prefix or for an aggregated
      prefix with a larger scope.  This essentially enables IPv4 routers



Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 17]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


      in that network to detect the local mobility anchor as the last-
      hop router for that IPv4 prefix.


   Forwarding Packets to the Mobile Node:

   o  On receiving a packet from a correspondent node with the
      destination address matching a mobile node's IPv4 home address,
      the local mobility anchor MUST forward the packet through the bi-
      directional tunnel setup for that mobile node.  The format of the
      tunneled packet is shown below.


        IPv6 header (src= LMAA, dst= Proxy-CoA       /* Tunnel Header */
           IPv4 header (src= CN, dst= IPv4-MN-HOA )  /* Packet Header */
              Upper layer protocols                  /* Packet Content*/



                  Figure 6: Tunneled Packets from LMA to MAG


   Forwarding Packets Sent by the Mobile Node:

   o  All the reverse tunneled packets that the local mobility anchor
      receives from the mobile access gateway, after removing the tunnel
      header MUST be routed to the destination specified in the inner
      IPv4 packet header.  These routed packets will have the source
      address field set to the mobile node's IPv4 home address.






















Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 18]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


4.  IPv4 Transport Support

   The Proxy Mobile IPv6 specification [ID-PMIP6] assumes the network
   between the local mobility anchor and the mobile access gateway to be
   an IPv6 network and requires the signaling messages exchanged between
   the local mobility anchor and the mobile access gateway to be over an
   IPv6 transport.  The extensions defined in this section allow the
   exchange of signaling messages over an IPv4 transport and when the
   local mobility anchor and the mobile access gateway are separated by
   an IPv4 network and potentially even configured with IPv4 private
   addresses and with NAT translation devices in the path.


             IPv4-Proxy-CoA                      IPv4-LMAA
                    |         + - - - - - - +        |
    +--+          +---+      /               \     +---+          +--+
    |MN|----------|MAG|=====   IPv4  Network  =====|LMA|----------|CN|
    +--+          +---+      \               /     +---+          +--+
                              + - - - - - - +



                     Figure 7: IPv4 Transport Network

   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 mechanism is
   extended to Proxy Mobile IPv6.  As explained in Section 4.1, of the
   [ID-DSMIP6], a mobile access gateway MUST send a Proxy Binding Update
   IPv6 message by IPv4 UDP-based encapsulation and route it to the
   local mobility anchor.  The processing logic and the on path NAT
   detection logic are just as described in Section 4.1.  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.





Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 19]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


4.1.  NAT Detection

   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 the 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
   MUST set the encapsulation mode of the tunnel to IPv4-UDP-based
   encapsulation.  The specific details around the NAT detection and the
   related logic is described in in DSMIPv6 specification [ID-DSMIP6].

   There are discussions on how to incorporate the NAT detection
   mechanism of IKE with DSMIPv6 in the MIP6 and the NEMO Working
   Groups.  This documentation will follow the conclusion of their
   discussions.

4.2.  Mobile Access Gateway Considerations

4.2.1.  Extensions to Binding Update List Entry

   For supporting this feature, the conceptual Binding Update List entry
   data structure needs to be extended with the following additional
   parameter, as specified in [ID-DSMIP6] specification and are reviewed
   here for convenience.

   o  The IPv4 Care-of address of the attached mobile node.  In this
      specification, it can be translated to IPv4 Care-of address of the
      mobile access gateway to which a mobile node is attached.

4.2.2.  Signaling Considerations

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


   Network Configurations for IPv4 Transport Signaling Support:

   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 obtain an IPv6 address
      configured for the Proxy Mobile IPv6 operation.  Even if the
      mobile access gateway does not have connectivity to the IPv6



Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 20]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


      network, it MUST configure with an IPv6 address for sending the
      proxy binding registration to the local mobility anchor.


   Processing Binding Registrations:

   o  As explained in 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.1.

   o  An example of proxy binding update sent by mobile access gateway
      is shown in Figure 8.  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).  This is slightly different from [ID-DSMIP6]
      .  The reason is already mentioned in Section 3.2.2.

   o  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).

   o  The IPv4-Proxy-CoA MUST be set in the IPv4 Care-of Address option
      defined in section 3.1.2 of [ID-DSMIP6].

   o  For the NAT handling, the UDP-based encapsulation MUST be always
      used for the proxy binding update.  The UDP port number is defined
      in [ID-DSMIP6].

   o  If the mobile access gateway requested to use the TLV header for
      the UDP encapsulation, it MUST insert a TLV header after the UDP
      header and MUST set T flag in the proxy binding update message.
      The format of the TLV header is defined in section 4.1 of [ID-
      DSMIP6].

   o  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.


   Constructing the Proxy Binding Update Message:

   o  The mobile access gateway when sending the Proxy Binding Update
      request to the local mobility anchor from an IPv4 networks MUST
      construct the message as specified below.





Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 21]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


              IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
                 UDP header
                   [TLV-header] (Optional, if T flag is set)
                   IPv6 header (src=Proxy-CoA, dst=LMAA)
                      Mobility header
                          -BU (P flag is set. F/T flags are optional)
                         Mobility Options
                            - Home Network Prefix Option
                            - IPv4 Home Address option
                            - Timestamp option (optional)
                            - Mobile Node Identifier Option
                            - Access Technology Type option (Mandatory)
                            - Mobile Node Interface Identifier option
                              (Optional)

                            - The IPv4 Care-of Address option(Mandatory)


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

   o  The IPv4 Care-of Address option [ID-DSMIP6] MUST be present.  The
      address value MUST be set to a mobile access gateway's IPv4
      address.

   o  All the other fields and the options MUST be constructed, as
      specified in [ID-PMIP6].


   Receiving Binding Registration Reply:

   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 Dual Stack Mobile IPv6 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 traffic.

   o  If the NAT is available and the NAT detection option is presented
      in the Proxy Binding Acknowledgment, the mobile access gateway
      MUST use the UDP tunnel to traverse the NAT for mobile node's
      traffic and MUST send a proxy binding update every refresh time
      specified in the NAT detection option.  The detailed operation can
      be found in Dual Stack Mobile IPv6 specification [ID-DSMIP6].





Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 22]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


   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.


   Forwarding Packets to Local Mobility Anchor

   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 9.  If the
      mobile access gateway and the local mobility anchor agreed to use
      the TLV header for the UDP tunnel during the binding registration,
      the TLV header MUST be presented after the UDP header as shown in
      Figure 10.


               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 9: Tunneled Packets from MAG to LMA



               IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
                   UDP header
                       TLV header
                       union {
                           IPv4 header (src=MN's IPv4-HoA, dst=IPv4 CN)
                           IPv6 header (src=MN's IPv6-HoA, dst=IPv6 CN)
                           IPsec
                           GRE
                       }
                               Upper layer protocols /*TCP,UDP,SCTP*/


       Figure 10: Tunneled Packets from MAG to LMA using the TLV header








Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 23]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


4.3.  Local Mobility Anchor Considerations

4.3.1.  Extensions to Binding Cache Entry

   For supporting this feature, the conceptual Binding Cache entry data
   structure needs to be extended with the following additional
   parameter as specified in [ID-DSMIP6] specification and are reviewed
   here for convenience.

   o  The IPv4 Care-of address of the attached mobile node.  In this
      specification, it can be translated to IPv4 Care-of address of the
      mobile access gateway to which a mobile node is attached.

4.3.2.  Signaling Considerations

   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 Dual Stack Mobile
   IPv6 specification for the use in Binding Acknowledgment message and
   extends it to Proxy Binding Acknowledgment messages.  The operational
   steps are defined below.


   Processing Binding Registrations:

   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.

   o  If the NAT is available, the local mobility anchor MUST use UDP
      encapsulation for the tunnel.

   o  If the T flag is set in the proxy binding update message and the
      TLV header is presented, the specified tunnel type must be used.

   o  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



Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 24]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


      are as specified in Section 5.3 of Proxy Mobile IPv6 specification
      [ID-PMIP6] and as in this specification.

   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.

   o  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.1.


   Constructing the Proxy Binding Acknowledgement Message:

   o  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.

   o  For the IPv4 transport support, no special mobility options are
      required.  Only when NAT is detected, the NAT detection option
      MUST be present.  The local mobility anchor MUST construct the
      proxy binding Acknowledgement as specified in [ID-PMIP6].

   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].


               IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA)
                   UDP header
                   [TLV-header] /* optional, if T flag is set */
                    IPv6 header (src=LMAA, dst=Proxy-CoA)
                       Mobility header
                           -BA /* P flag/T flag(option) */
                          Mobility Options
                             - Home Network Prefix Option
                             - IPv4 Address Acknowledgement option
                             - Timestamp option (optional)
                             - Mobile Node Identifier Option
                             - Access Technology Type option (Mandatory)
                             - Mobile Node Interface Identifier option
                               (Optional)

                             - NAT Detection Option (Optional)


           Figure 11: Proxy Binding Acknowledgment in IPv4 network



Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 25]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


   Forwarding Packets to Mobile Access Gateway

   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 12.


               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 12: Tunneled Packets from LMA to MAG

   o  If the mobile access gateway and the local mobility anchor agreed
      to use the TLV header for the UDP tunnel during the binding
      registration, the TLV header MUST be presented after the UDP
      header as shown in Figure 13.


               IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
                   UDP header
                       TLV header
                       union {
                           IPv4 header (src=IPv4-CN, dst=IPv4-HoA)
                           IPv6 header (src=IPv6-CN, dst=IPv6-HoA)
                           IPsec
                           GRE
                       }
                               Upper layer protocols /*TCP,UDP,SCTP*/


       Figure 13: Tunneled Packets from LMA to MAG using the TLV header

4.4.  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.






Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 26]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


5.  IANA Considerations

   This document does not require IANA Action.
















































Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 27]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


6.  Security Considerations

   The security mechanisms specified for Proxy Mobile IPv6 protocol are
   used when using the extensions defined in this document.

   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 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.  Moreover, all the DHCP
   messages between a DHCP relay and the 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.

   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].





















Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 28]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


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@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-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.




Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 29]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


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

   [RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
   Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283,
   November 2005.

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

   [ID-PMIP6] Gundavelli, S., et.al, "Proxy Mobile IPv6",
   draft-ietf-netlmm-proxymip6-07.txt, November 2007.

9.2.  Informative References

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

   [RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
   Address Translator (Traditional NAT)", RFC 3022, January 2001.

   [RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack
   Mobility", RFC 4977, August 2007.



























Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 30]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


Appendix A.  DHCP usages for IPv4 home address assignment

   There are several other configurations of DHCP entities [RFC-2131] in
   a Proxy Mobile IPv6 domain other than the two configurations listed
   in Section 3.1.  Although this specification recommends the two
   configurations described in Section 3.1, operators should select the
   best configuration according to their deployments scenario.  Note
   that the mobile node behavior for all scenarios does not change.  We
   do not have major interoperability concerns between multiple
   scenarios.  A mobile access gateway and local mobility anchor make
   sure that which option is used in the Proxy Mobile IPv6 domain based
   on the deployment scenario.

   In the configurations described in this section, the DHCP messages
   MAY be sent across an administrative boundaries.  The operators
   SHOULD consider to protect these messages crossing the administrative
   boundary.  The optional DHCP configurations for IPv4 home address
   assignment are described below.

   o  DHCP relay is located in each mobile access gateway and DHCP
      server is solely located in the Proxy Mobile IPv6 domain

   o  DHCP relay is located in both each mobile access gateway and a
      local mobility anchor.  DHCP server is solely located in the Proxy
      Mobile IPv6 domain

   In Figure 14, a DHCP relay is co-located with each mobile access
   gateway.  The DHCP server is located independently in a Proxy Mobile
   IPv6 domain.  Thus, the address assignment is done between the mobile
   access gateway and the DHCP server, but not with the local mobility
   anchor.  A mobility anchor gateway is configured with the DHCP server
   address and relays the DHCP discovery message from the mobile node to
   the DHCP server.  While the DHCP server offers the IPv4 home address
   to the mobile node, the mobile access gateway intercepts the DHCP
   offer and starts sending proxy binding update to the local mobility
   anchor.  As soon as proxy binding registration is completed, the
   mobile access gateway sends the DHCP offer back to the mobile node.
   The mobile node will send DHCP request and wait for the DHCP
   Acknowledgement to/from the DHCP server through the mobility anchor
   gateway (i.e.  DHCP relay).  When multiple local mobility anchors are
   available in the Proxy Mobile IPv6 domain, each mobile access gateway
   must ensure to relay the DHCP messages to the right DHCP server.









Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 31]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


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


              Figure 14: The use of an Independent DHCP relay

   Figure 15 is very similar to the Figure 14 except for the local
   mobility anchor being a DHCP relay.  In this case, both a mobile
   access gateway and local mobility anchor relay the DHCP messages from
   and to the mobile nodes.


     MN  MAG(DHCP-R) LMA(DHCP-R) DHCP-S
      |------>|------->|------>|  1. DHCP discovery and Relay
      |<------|<-------|<------|  2. DHCP offer (IPv4 HoA) and Relay
      |------>|------->|------>|  3. DHCP request (IPv4 HoA) and Relay
      |       |<-------|<------|  4. DHCP acknowledgement and Relay
      |       |------->|       |  5. Proxy Binding Update
      |       |<-------|       |  6. Proxy Binding Acknowledgement
      |       |========|       |  7. Tunnel/Route Setup
      |<------|        |       |  8. DHCP acknowledgement to client
      |       |        |       |
      * Tunnel setup(no.5) and DHCP offer/request/ack(no.6-8)
        are processed in parallel.


          Figure 15: The use of double DHCP relays on MAG and LMA
















Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 32]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


Authors' Addresses

   Ryuji Wakikawa (Editor)
   Faculty of Environment and Information Studies, Keio University
   5322 Endo
   Fujisawa, Kanagawa  252-8520
   Japan

   Phone: +81-466-49-1100
   Fax:   +81-466-49-1395
   Email: ryuji@sfc.wide.ad.jp
   URI:   http://www.wakikawa.org/


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

   Email: sgundave@cisco.com






























Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 33]


Internet-Draft     IPv4 Support for Proxy Mobile IPv6      November 2007


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





Wakikawa (Editor) & Gundavelli  Expires May 22, 2008           [Page 34]


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