NETLMM Working Group                                         R. Wakikawa (Editor)
Internet-Draft                                           Keio University                                                Toyota ITC
Intended status: Standards Track                           S. Gundavelli
Expires: November 23, 2008 January 15, 2009                                          Cisco
                                                            May 22,
                                                           July 14, 2008

                   IPv4 Support for Proxy Mobile IPv6
              draft-ietf-netlmm-pmip6-ipv4-support-03.txt
              draft-ietf-netlmm-pmip6-ipv4-support-04.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 23, 2008. January 15, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document specifies extensions to Proxy Mobile IPv6 protocol for
   supporting
   adding IPv4 protocol. protocol support.  The scope of this IPv4 protocol support includes
   the support for the mobile node's is
   two-fold: 1) For extending IPv4 home address mobility and for support to the
   mobile node. 2) For allowing the mobility entities in the Proxy
   Mobile IPv6 domain to exchange signaling messages over an IPv4 transport.
   transport network.

Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4  5
     1.1.  Stated Assumptions . . . . . . . . . . . . . . . . . . . .  5  6

   2.  Conventions & Terminology  . . . . . . . . . . . . . . . . . .  7  8
     2.1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  7  8
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  7  8

   3.  IPv4 Home Address Mobility Support . . . . . . . . . . . . . .  8 10
     3.1.  IPv4 Home Address Assignment  Local Mobility Anchor Considerations . . . . . . . . . . . 11
       3.1.1.  Extensions to Binding Cache Entry  . . . .  8
     3.2.  Mobile Access Gateway Considerations . . . . . . 11
       3.1.2.  Signaling Considerations . . . . . . . . 11
       3.2.1.  Extensions to Binding Update List Entry . . . . . . . 11
       3.2.2.  Signaling
       3.1.3.  Routing Considerations for the Local Mobility
               Anchor . . . . . . . . . . . . . . . 11
     3.3.  Local Mobility Anchor . . . . . . . . . 15
     3.2.  Mobile Access Gateway Considerations . . . . . . . . . . . 15
       3.3.1. 16
       3.2.1.  Extensions to Binding Cache Update List Entry  . . . . . . . 16
       3.2.2.  Extensions to Mobile Node's Policy Profile . . . 15
       3.3.2. . . . 16
       3.2.3.  Signaling Considerations . . . . . . . . . . . . . . . 16
       3.3.3. 17
       3.2.4.  Routing Considerations for the Mobile Access
               Gateway  . . . . . . . . . . . . . . . . 18
     3.4.  Mobility Options . . . . . . . . . 19
     3.3.  Mobility Options and Status Codes  . . . . . . . . . . . . 19
       3.4.1.
       3.3.1.  IPv4 Default Router Default-Router Address Option . . . . . . . . . . 19

   4.  IPv4 Transport Support
       3.3.2.  Status Codes . . . . . . . . . . . . . . . . . . . . . 20
     4.1.  NAT Support
     3.4.  Supporting DHCP Based Address Configuration  . . . . . . . 21
       3.4.1.  DHCP Server co-located with the Mobile Access
               Gateway  . . . . . . . . . . . . . . . . . . . . 21
     4.2. . . . 22
       3.4.2.  DHCP Relay Agent co-located with the Mobile Access
               Gateway Considerations  . . . . . . . . . . . 22
       4.2.1.  Extensions to Binding Update List Entry . . . . . . . 22
       4.2.2.  Signaling Considerations . . . . . 25

   4.  IPv4 Transport Support . . . . . . . . . . . . . 22
     4.3. . . . . . . . 28
     4.1.  Local Mobility Anchor Considerations . . . . . . . . . . . 25
       4.3.1. 29
       4.1.1.  Extensions to Binding Cache Entry  . . . . . . . . . . 25
       4.3.2.  Signaling Considerations 29
       4.1.2.  Extensions to Mobile Node's Policy Profile . . . . . . 30
       4.1.3.  Signaling Considerations . . . . . . . . . . 25
     4.4.  Tunnel Management . . . . . 30
       4.1.4.  Routing Considerations . . . . . . . . . . . . . . . 28

   5.  IANA . 32
     4.2.  Mobile Access Gateway Considerations . . . . . . . . . . . 34
       4.2.1.  Extensions to Binding Update List Entry  . . . . . . . 34
       4.2.2.  Signaling Considerations . . . 29 . . . . . . . . . . . . 34

   5.  Protocol Configuration Variables . . . . . . . . . . . . . . . 38
     5.1.  Local Mobility Anchor - Configuration Variables  . . . . . 38
     5.2.  Mobile Access Gateway - Configuration Variables  . . . . . 38
     5.3.  Proxy Mobile IPv6 Domain - Configuration Variables . . . . 39

   6.  Security  IANA Considerations  . . . . . . . . . . . . . . . . . . . 30 . . 40

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 41
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31

   8. 42

   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 31
   9. 42

   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     9.1. 42
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 31
     9.2. 42
     10.2. Informative References . . . . . . . . . . . . . . . . . . 32

   Appendix A.  DHCP usages for IPv4 home address assignment  . . . . 33 43

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 44
   Intellectual Property and Copyright Statements . . . . . . . . . . 35 45

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
   or an IPv6 network.  It is also reasonable to expect the same
   mobility infrastructure in a the Proxy Mobile IPv6 domain to provide
   mobility to the mobile nodes 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 or an IPv6 network.  The motivation and
   scope of IPv4 support in Mobile IPv6 is summarized in [RFC-4977] and
   all those requirements apply to Proxy Mobile IPv6 protocol as well.

   The Proxy Mobile IPv6 protocol[ID-PMIP6] protocol [RFC-5213] 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 domain.  The protocol requires IPv6 transport
   network
   separating the entities involved in between the mobility management. entities.  The extensions defined in
   this document are for extending extends IPv4 support to the Proxy Mobile IPv6 protocol [ID-PMIP6].
   [RFC-5213].

   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 an 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 Network 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 an IPv4 private addresses address 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 some of on the
   options related to IPv4 support and some processing logic for
   extending IPv4 support path to Proxy Mobile IPv6 protocol. the local mobility
      anchor.

   These two features, the IPv4 Home Address Mobility support and the
   IPv4 transport support features, are independent of each other and
   deployments can may choose to enable any one or both of these features.

   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. features as
   required.

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

               Figure 1: IPv4 support for Proxy Mobile IPv6

1.1.  Stated Assumptions

   o  This specification requires that

   Following are the configuration requirements from the mobility
   entities in the Proxy Mobile IPv6 domain for supporting the
   extensions defined in this document.

   o  The local mobility anchor and the mobile access gateway are both IPv6 capable
      IPv4 and IPv6 enabled.  Irrespective of the type of transport
      network (IPv4 or IPv6) separating these two entities (i.e., if the entities are reachable
      using an IPv4 or IPv6 transport address), entities, the mobility
      signaling is always based on Proxy Mobile IPv6.

   o  For supporting IPv4/IPv6 home address mobility, the transport
      network between the local mobility anchor and the mobile access
      gateway can be an IPv6 network or an IPv4 network.  However, for
      supporting IPv4 transport network feature, as implied, IPv4
      transport network is required. [RFC-5213].

   o  The mobile node can be operating in IPv4-only, IPv6-only or in
      dual mode.  If enabled, the  Based on what is enabled for a mobile node node, it should
      be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6
      address(es) on for its
      interface. interface and further achieve mobility support
      for those addresses.

   o  For enabling IPv4 home address mobility support to a mobile node,
      it is not required that the IPv6 home address mobility support
      needs to enabled.  However, the respective protocol(s) support
      must be enabled on the access link between the mobile node and the
      mobile access gateway.

   o  There can be support for multiple IPv4 home network prefixes for
      the mobile node's attached interface.  The mobile node should be
      able to can obtain one or more IPv4 addresses from one or all of for its
      IPv4 home network prefixes.
      attached interface.  Based on the type of link, it may be able to
      acquire its IPv4 address configuration using DHCP, IPCP, DHCP [RFC-2131], IPCP
      [RFC-1332], IKEv2 [RFC-4306], static configuration or through
      other standard IPv4 address configuration mechanisms.

   o  The mobile node's IPv4 home network prefix subnet is typically a shared prefix
      (unlike its IPv6 home network prefix, which address
      space.  Its is a shared prefix). not for the exclusive use of any one mobile node.
      There can be more than one mobile node sharing address(es) different addresses
      from the same IPv4 home network prefix. subnet.

   o  The mobile access gateway is always the IPv4 default-router for the
      mobile node on its access link.  It will always be able to
      receive traffic sent to in the forwarding path
      for the mobile node's IPv4 default-router
      address. data traffic.

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 the Mobile IPv6 specification [RFC-3775]
   and Proxy Mobile IPv6 specification [ID-PMIP6]. [RFC-5213].  In addition the this
   document introduces the following terms.

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

      The IPv4 address that is configured on the interface egress-interface of the
      mobile access gateway and is gateway.  When using IPv4 transport, this address
      will be the transport endpoint of registered care-of address in the tunnel between
      a local mobility anchor and a mobile access gateway.  This address node's
      Binding Cache entry and will also be used as the source address for the signaling messages sent
      by transport-endpoint of the mobile access gateway to
      tunnel between the local mobility anchor and will
      be the registered Care-of address in the a mobile node's Binding
      Cache entry. access
      gateway.  However, when if 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 egress-interface of the tunnel
      between the
      local mobility anchor and the mobile access gateway.
      This is the address to where anchor.  When using IPv4 transport, the mobile
      access gateway sends the Proxy Binding Update messages when using IPv4 transport.  If the
      local mobility anchor is configured to be behind a NAT device, this
      address and will not be directly configured on the local mobility
      anchor, but a corresponding mapped private address will be
      configured on transport-endpoint of the tunnel between
      the local mobility anchor. anchor and the mobile access gateway.

   Mobile Node's IPv4 Home Network Prefix (IPv4-MN-HNP) Address (IPv4-MN-HoA)

      This is the IPv4 prefix from which home address assigned to the mobile node obtains its
      home address(es). node's
      attached interface.  This IPv4 home network prefix address is topologically
      anchored at the mobile node's local mobility anchor.  The mobile node configures its interface with address(es) from
      this prefix.

3.  IPv4 Home Address Mobility Support

   An address on its attached interface.  There can be more than
      one IPv4 enabled home addresses assigned to the mobile node's attached
      interface.  Further, if the mobile node when it attaches connects to the Proxy
      Mobile IPv6
   domain, domain through multiple interfaces and for
      simultaneous access, each of the network attached interfaces will ensure be
      assigned a unique set of IPv4 home addresses and all the IPv4
      addresses that are assigned to a given interface of a mobile node
      will be able to
   obtain an IPv4 address (IPv4-MN-HoA) from its home network prefix for managed under one mobility session.

   Encapsulation Modes

      This document uses the interface attached following terms when referring to the access network
      different encapsulation modes.

      IPv4-over-IPv6

         IPv4 packet carried as a payload of an IPv6 packet

      IPv4-over-IPv4

         IPv4 packet carried as a payload of an IPv4 packet

      IPv4-over-IPv4-UDP

         IPv4 packet carried as a payload in an UDP header of an IPv4
         packet

      IPv4-over-IPv4-UDP-TLV

         IPv4 packet carried as a payload in an IPv4 packet with UDP and
         TLV headers

3.  IPv4 Home Address Mobility Support

   The IPv4 home address mobility support essentially enables a mobile
   node in a Proxy Mobile IPv6 domain to obtain IPv4 home address
   configuration for its attached interface and be able to retain that
   address configuration even after changing its point of attachment in
   that Proxy Mobile IPv6 domain.  Using  This section describes the protocol
   operation and the required extensions defined in this specification, to Proxy Mobile IPv6 protocol
   for supporting IPv4 home address mobility support.

   When an IPv4-enabled or a dual-stack enabled mobile node attaches to
   the Proxy Mobile IPv6 domain, the mobile access gateway on the access
   network where the mobile node is attached will exchange identify the mobile
   node and will initiate the Proxy Mobile IPv6 signaling messages with the
   mobile node's local mobility anchor.  The mobile access gateway will
   follow the signaling considerations specified in Section 3.2 for
   requesting IPv4 home address support.  Upon the completion of the
   signaling the local mobility anchor and the mobile access gateway
   will setup have the required routing state states for that home address.

   If allowing the mobile node connects to use its
   IPv4 home address(es) from the current point of attachment.

   The mobile node on the Proxy Mobile IPv6 domain, through
   multiple interfaces and simultaneously through different access
   networks, each link using any of the connected interfaces will obtain an address
   from a unique standard IPv4 home network prefix.  In
   address configuration mechanisms supported on that access link, such configuration, there
   as IPCP [RFC-1332], IKEv2 [RFC-4306] or using DHCP [RFC-2131], will
   be multiple Binding Cache entries on able to obtain one or more IPv4 home addresses (IPv4-MN-HoA) for
   the local mobility anchor attached interface.  Although the address configuration protocol
   mechanisms for that delivering the address configuration to the mobile
   node and with one entry for each connected interface,
   as specified in is independent of the Proxy Mobile IPv6 protocol operation,
   however there needs to be some interactions between these two
   protocol flows.  Section 5.4 [ID-PMIP6]. 3.4 identifies these interactions for
   supporting DHCP based address configuration.

   The support for IPv4 addressing home address mobility is orthogonal to not dependent on the
   IPv6 addressing home address support.  Unlike as specified in [ID-DSMIP6], the  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 configuration on the connected its attached interface.
   The mobile nodes' node's policy profile 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 if the mobile node after obtaining the
   IPv4 or IPv4/IPv6 address
   configuration on the access link, its interface performs an inter-technology handoff, either by
   changing its point of attachment over the same interface or to a
   different interface, the network will ensure the mobile node will be
   able to use the same IPv4/IPv6 IPv4 address configuration on after the
   new interface.  [RYUJI The IPv4 home address MUST be handoff.

   Additionally, If the global IPv4
   address.  A private IPv4 address assignment as an IPv4 home address
   is prohibited.  There is no gurantee mobile node connects to assign the Proxy Mobile IPv6
   domain, through multiple interfaces and simultaneously through
   different access networks, each of the connected interfaces will
   obtain one or more IPv4 private home
   address which is different addresses from different subnets.  In
   such scenario, there will be multiple Binding Cache entries for the private address configured at a
   mobile access gateway.]

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 local mobility service, the mobile node using any of anchor.  All the IPv4 address configuration procedures, such (IPv4/
   IPv6) assigned to a given interface will be managed as DHCP [RFC-2131], IPCP or
   IKEv2 that are supported on that access link, will be able part of one
   mobility session, as specified in Section 5.4 of [RFC-5213].

3.1.  Local Mobility Anchor Considerations

3.1.1.  Extensions to obtain
   required information for its IPv4 home address configuration.  The
   required information includes the IPv4 home address, Binding Cache Entry

   For supporting this feature, the IPv4 home
   network prefix, IPv4 home network prefix length and conceptual Binding Cache entry data
   structure maintained by the IPv4 default
   router address.

   When a mobile node is configured local mobility anchor needs to be
   extended with a static IPv4 home address, the following additional parameters.

   o  List of IPv4 home address information SHOULD be stored in addresses assigned to the mobile node's
   policy profile.  The mobile access gateway where the mobile node
   attached obtains the static IPv4 home address from
      interface registered by the policy
   profile.  The mobile access gateway MUST use either the obtained gateway.  Each of these
      IPv4 home address or entries also include the obtained corresponding prefix
      length.

   o  The IPv4 home subnet default-router address assigned to initialize the mobile node.

3.1.2.  Signaling Considerations

3.1.2.1.  Processing Proxy Binding Updates

   The processing rules specified in Section 5.3 of [RFC-5213] are
   applied for processing the received Proxy Binding Update message.
   However, if the received Proxy Binding Update message has one or more
   IPv4 Home Address and Pref fields in options, the following additional considerations
   MUST be applied.

   o  If there is an IPv4 Home Address option
   [ID-DSMIP6].  This option is carried by a proxy binding update
   described present in [ID-PMIP6].

   On the other hand, received
      Proxy Binding Update message, but if DHCP there is used for no Home Network
      Prefix option present in the IPv4 home address
   allocation request, the local mobility anchor
      MUST NOT reject the request 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
   IPv4 address from its home network subnet.  All the IPv4 home
   addresses assigned to mobile nodes must Section 5.3.1 of [RFC-
      5213].  At least one instance of any of these two options 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.  There are several
   configurations where the DHCP entities are located in
      present.  However, if not a Proxy Mobile
   IPv6 domain.  This document recommends following two configurations.
   The other configurations single instance of any of these
      options are explained in Appendix A.

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

   2.  DHCP server is co-located with a not present, the local mobility anchor MUST reject the
      request and send a DHCP
       relay is co-located Proxy Binding Acknowledgement message with each
      Status field set to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing
      mobile access gateway

   Figure 2 shows node's home network prefix option).

   o  For performing the operational sequence of Binding Cache entry existence test, the home address
   assignment when a DHCP server
      following considerations MUST be applied:

      *  If there is co-located at least one Home Network Prefix option with each mobile access
   gateway.  In this scenario, a DHCP server which
         NON_ZERO prefix value, or, if there is also a mobile
   access gateway interacts no IPv4 Home Address
         option with a DHCP client on a mobile node.  All
   mobile access gateways SHOULD support minimal functionality NON_ZERO IPv4 address, considerations from
         Section 5.4 of a DHCP
   server in order to send DHCP offer and acknowledgment messages to the
   mobile node [RFC-5213] MUST be applied.

      *  If there is at least one IPv4 Home Address option present in reply to
         the DHCP discovery and request messages.
   While the mobile access gateway is seen as a DHCP server from with a
   mobile node, it actually obtains the NON_ZERO IPv4 home address for each
   mobile node value, considerations
         from Section 3.2.2.7 MUST be applied.

   o  If there is no existing Binding Cache entry that can be associated
      with the request, the local mobility anchor during proxy MUST consider this
      request as an initial binding
   procedure (set 0.0.0.0 in registration request and
      considerations from Section 3.2.2.2 MUST be applied.

   o  If there exists a Binding Cache entry that can be associated with
      the request, the IPv4 Home Address field local mobility anchor MUST apply considerations
      from Section 5.3.1 of [RFC-5213], (point 13), to determine if the
      request is re-registration request or a de-registration request
      and the respective considerations from below MUST be applied.

3.1.2.2.  Initial Binding Registration (New Mobility Session)

   o  If there is at least one IPv4
   home address Home Address option as described present in [ID-DSMIP6]).  After MAG
   receiving the assigned
      Proxy Binding Update message with the IPv4 address from LMA, it assigns value set to
      ALL_ZERO, the address local mobility anchor MUST allocate one or more IPv4
      home addresses to the requesting mobile node and associate them to the new
      mobility session created for that mobile node.  Note  The decision on
      how many IPv4 home addresses to be allocated can be based on a
      domain-wide policy or a policy specific to that the mobile access gateway
   MUST return its own IP node.

   o  If there are one or more IPv4 Home Address options present in the
      received Proxy Binding Update message (with the IPv4 address field
      in the 'server identifier' option when
   sending DHCP messages set to a NON_ZERO value), the mobile node.  Thus, whenever local mobility anchor
      before accepting the request, MUST ensure the address is owned by
      the local mobility anchor and further the mobile node changes is
      authorized to use that address.  If the attached mobile access gateway, this server
   identifier must be updated.  The detail can be found in
   Section 3.2.2.  The second scenario does node is not have this server
   identifier change when
      authorized for a mobile node changes its mobile access
   gateway.  Any information carried in DHCP options such as addresses
   of domain name server, time server, lpr server, etc. specific address, the local mobility anchor MUST be
   configured in all
      reject the DHCP server located at mobile access gateways
   if necessary.

     MN   MAG(DHCP-S)  LMA
      |------>|        |    1. DHCP discovery
      |       |------->|    2. Proxy Binding Update *
      |       |<-------|    3. request and send a Proxy Binding Acknowledgement (IPv4HoA)
      |       |========|    4. Tunnel/Route Setup*
      |<------|        |    5. DHCP offer (IPv4 HoA)
      |------>|        |    6. DHCP request (IPv4 HoA)
      |<------|        |    7. DHCP acknowledgement
      |       |        |
      * DHCP discovery (no.1) and PBU (no.2) are operated in parallel.
      * Tunnel/Route setup(no.4) and DHCP offer/request/ack(no.5-7)
        are processed
      message with Status field set to
      NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized
      for the requesting IPv4 Home Address).  It MUST also set the
      status field value in parallel.

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

   In Address
      Acknowledgement option [ID-DSMIP6] to 129 (Administratively
      prohibited).

   o  If 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.  A mobile access gateway sends a proxy binding update and
   retrieves anchor is unable to allocate an IPv4 home address for
      due to lack of resources, it MUST reject the mobile node from request and send a
      Proxy Binding Acknowledgement message with Status field set to 130
      (Insufficient resources).  It MUST also set the local
   mobility anchor as described status field value
      in the first scenario.  When the mobile
   access gateway relays DHCP messages corresponding IPv4 Address Acknowledgement option [ID-
      DSMIP6], to 128 (Failure, reason unspecified).

   o  Upon accepting the DHCP server, it includes request, the assigned local mobility anchor MUST create
      a Binding Cache entry for this mobility session.  However, if the
      request also contains one or more Home Network Prefix options,
      there should still be only one Binding Cache entry that should be
      created for this mobility session.  The created Binding Cache
      entry MUST be used for managing both IPv4 and IPv6 home address information in the DHCP messages as a
   hint.
      bindings.  The DHCP server SHOULD assign the address stored fields in the hint Binding Cache entry MUST be updated
      with the accepted values for that binding.

   o  The local mobility anchor MUST establish a bi-directional tunnel
      to the mobile node.  Figure 3 are access gateway and with the sequence of IPv4 home address
   assignment encapsulation mode as
      negotiated.  When using DHCP Relay.  The DHCP discovery message is sent by a
   mobile node at any time, but IPv6 transport, the DHCP relay SHOULD NOT relay encapsulation mode is
      IPv4 over IPv6.

   o  The local mobility anchor MUST create IPv4 host route(s) for
      tunneling the DHCP
   discovery message before it learns packets received for any of the IPv4 mobile node's home address hint during
      address(es) associated with this mobility session.

   o  The local mobility anchor MUST send the proxy binding registration.  As shown in Figure 3, Proxy Binding
      Acknowledgement message with the DHCP
   messages MAY be sent across an administrative boundaries. Status field set to 0 (Proxy
      Binding Update Accepted).  The
   operators message MUST ensure to secure these messages.  More remarks can be
   found constructed as
      specified in Section 6. 3.1.2.6.

3.1.2.3.  Binding Lifetime Extension (No handoff)

   All the consideration from Section 5.3.2 of [RFC-5213] MUST be
   applied.

3.1.2.4.  Binding Lifetime Extension (After handoff)

   o  The DHCP server identifier remains local mobility anchor MUST remove the same all previously created host
      route(s), towards the time, because mobile access gateway where the server is uniquely located at mobile node
      was anchored prior to the handoff.

   o  The local mobility anchor.

     MN   MAG(DHCP-R)  LMA(DHCP-S)
      |       |------->|    1. anchor MUST create a host route(s) for
      tunneling the packets received for any of the mobile node's home
      address(es) associated with this mobility session.

   o  The required forwarding state identified in Section 5.3.6 of [RFC-
      5213] is for IPv6 payload traffic.  Those considerations apply for
      IPv4 payload traffic as well.  However, if IPv4 transport is in
      use, considerations from Section 4.0 MUST be applied.

3.1.2.5.  Binding De-Registration

   All the consideration from Section 5.3.5 of [RFC-5213] MUST be
   applied.  Additionally, for removing the routing state as part of the
   Binding Cache entry deletion, any IPv4 host route(s) added for this
   mobility session MUST be removed.

3.1.2.6.  Constructing the Proxy Binding Update *
      |       |<-------|    2. Acknowledgement Message

   The local mobility anchor when sending the Proxy Binding
   Acknowledgement (IPv4HoA)
      |       |========|    3. Tunnel/Route Setup*
      |------>|------->|    4. DHCP discovery (IPv4HoA) via DHCP-R
      |<------|<-------|    5. DHCP offer (IPv4 HoA) via DHCP-R
      |------>|------->|    6. DHCP request (IPv4 HoA) via DHCP-R
      |<------|<-------|    7. DHCP acknowledgement via DHCP-R
      |       |        |
      * Tunnel/Route setup(no.3) and DHCP offer/request/ack(no.4-7)
        are processed message to the mobile access gateway MUST construct
   the message as specified in parallel.

                      Figure 3: The use Section 5.3.6 of DHCP relay

3.2.  Mobile Access Gateway Considerations

3.2.1.  Extensions [RFC-5213].
   Additionally, the following considerations MUST be applied.

   o  Section 5.3.6 of [RFC-5213] requires the local mobility anchor to
      include at least one instance of Home Network Prefix option in the
      Proxy Binding Acknowledgement message that it sends to the mobile
      access gateway.  However, if the received Proxy Binding Update List Entry

   For supporting this feature,
      message has only the IPv4 Home Address option and did not contain
      the Home Network Prefix option(s), then the local mobility anchor
      MUST NOT include the Home Network Prefix option in the reply.

   o  The IPv4 Address Acknowledgement option(s) MUST be present in the
      Proxy Binding Acknowledgement message.

      1.  If the Status field is set to a value greater than or equal to
          128, i.e., if the Proxy Binding Update is rejected, then there
          MUST be an IPv4 Address Acknowledgement option for each of the
          IPv4 Home Address options present in the request and with the
          address value and the prefix length in the option set to the
          values present in the corresponding request option.  The
          status field value in the option must be set to the specific
          error code.

      2.  For all other cases, there MUST be an IPv4 Address
          Acknowledgement option for each of the assigned IPv4 home
          addresses assigned for that mobility session and with the
          value in the option set to the allocated address value.  The
          prefix length in the option MUST be set to the prefix length
          of the allocated address.  The status field value in the
          option must be set to 0 (Success).

   o  The IPv4 Default-Router Address option MUST be present, if the
      Status field value in the Proxy Binding Acknowledgement message is
      set to 0 (Proxy Binding Update Accepted).  Otherwise, the option
      MUST NOT be present.  If the option is present, the default-router
      address in the option MUST be set to the mobile node's default-
      router address.

3.1.2.7.  Binding Cache Entry Lookup Considerations

   The Binding Cache entry lookup considerations specified in Section
   5.4.1.1 of [RFC-5213] is for using the Home Network Prefix as the key
   parameter for identifying the Binding Cache entry.  When using an
   IPv4 address with a NON_ZERO value, the exact same considerations
   specified in Section 5.4.1.1 of [RFC-5213] MUST be applied, with the
   exception of using an IPv4 home address in place of an IPv6 home
   network prefix.

3.1.3.  Routing Considerations for the Local Mobility Anchor

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

   o  When the local mobility anchor is serving a mobile node, it MUST
      be able to receive packets that are sent to any of the mobile
      node's IPv4 addresses.  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 address or for its
      home subnet.  This essentially enables IPv4 routers in that
      network to detect the local mobility anchor as the last-hop router
      for that subnet.

   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.

   o  The format of the tunneled packet when payload protection is not
      enabled:

        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 2: 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.

3.2.  Mobile Access Gateway Considerations

3.2.1.  Extensions to Binding Update List Entry

   For supporting the IPv4 home address mobility feature, the conceptual
   Binding Update List entry data structure needs to be extended with
   the following additional fields.

   o  List of IPv4 home addresses assigned to the mobile node's attached
      interface.  These IPv4 home addresses may have been statically
      configured in the mobile node's policy profile, or, may have been
      dynamically allocated by the local mobility anchor through the
      received Proxy Binding Acknowledgement message.  Each of these
      IPv4 home address entries also includes the corresponding subnet-
      mask.

   o  The IPv4 default-router address of the mobile node.  This is
      acquired from the mobile node's local mobility anchor through the
      received Proxy Binding Acknowledgment message.

3.2.2.  Extensions to Mobile Node's Policy Profile

   For supporting this feature the mobile node's policy profile,
   specified in Section 6.2 of [RFC-5213] MUST be extended with the
   following additional fields.

   Extensions to the mandatory section of the policy profile:

   o  This field indicates the scope of IP address mobility support that
      needs to be extended for the mobile node.  If the mobile access
      gateway should enable support for IPv4, IPv6 or IPv4/IPv6 home
      address mobility support.

   Extensions to the optional section of the policy profile:

   o  The IPv4 home addresses assigned to the mobile node's attached
      interface.  These addresses have to be maintained on a per-
      interface basis.  The specific details on how the network
      maintains the association between the addresses and the interfaces
      is outside the scope of this document.  These address entries also
      include the corresponding prefix length.

3.2.3.  Signaling Considerations

3.2.3.1.  Mobile Node Attachment and Initial Binding Registration

   After detecting a new mobile node on its access link, the mobile
   access gateway on the access link MUST determine if IPv4 home address
   mobility support needs to be enabled for that mobile node.  The
   mobile node's policy profile specifies if IPv4-only, IPv6-only or
   IPv4/IPv6 home address mobility service needs to be enabled for that
   mobile node.  Based on those policy considerations, if it is
   determined that IPv4 home address mobility support is required to be
   enabled for the mobile node, the considerations from section 6.9.1.1
   of [RFC-5213] MUST be applied with the following exceptions.

   o  The IPv4 Home Address option(s) MUST be present in the Proxy
      Binding Update request.

      *  If the mobile access gateway learns the mobile node's IPv4 home
         address(es) either from its policy profile, or from other means
         the mobile access gateway MAY choose to request the local
         mobility anchor to allocate the requested addresses by
         including an IPv4 Home Address option for each of those
         addresses.  The IPv4 address and the prefix length fields in
         the option MUST be set to that specific address and its prefix
         length.  The (P) flag in the option MUST be set to 0.

      *  The mobile access gateway MAY also choose to request the local
         mobility anchor for dynamic home address allocation.  It can
         include exactly one instance of the IPv4 home address option
         with the IPv4 address value, prefix length fields and (P) flag
         in the option set to a ALL_ZERO value.  This essentially serves
         as a request to the local mobility anchor for the IPv4 home
         address allocation.

   o  The Proxy Binding Update message MUST be constructed as specified
      in Section 6.9.1.5.  However, the Home Network Prefix option(s)
      MUST be present in the Proxy Binding Update only if IPv6 home
      address mobility support also needs to be enabled for the mobile
      node.  Otherwise, the Home Network Prefix option(s) MUST NOT be
      present.

   o  When using IPv4 transport for carrying the signaling messages, the
      related considerations from section 4.0 MUST be applied.

3.2.3.2.  Receiving Proxy Binding Acknowledgement

   All the considerations from section 6.9.1.2 of [RFC-5213] MUST be
   applied with the following exceptions.

   o  If the received Proxy Binding Acknowledgement message has the
      Status field value set to
      NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS_SUPPORT (The mobile node is
      not authorized for IPv4 home address support), the mobile access
      gateway SHOULD NOT send a Proxy Binding Update message including
      the IPv4 Home Address option(s) till an administrative action is
      taken.

   o  If the received Proxy Binding Acknowledgement message has the
      Status field value set to NOT_AUTHORIZED_FOR_REQ_IPV4_HOME_ADDRESS
      (The mobile node is not authorized for the requesting IPv4 home
      address), the mobile access gateway SHOULD NOT request for the
      same address again, but MAY request the local mobility anchor to
      do the assignment of address by including exactly one instance if
      IPv4 Home Address option with the address value set to ALL_ZERO.

   o  If there is no IPv4 Address Acknowledgement option present in the
      received Proxy Binding Acknowledgement message, the mobile access
      gateway MUST NOT enable IPv4 support for the mobile node and the
      rest of the considerations from this section can be skipped.

   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
      forwarding for that specific IPv4 home address.

   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 for
      that mobile node.  The entry MUST be updated with the assigned
      IPv4 home address(es).

   o  The bi-directional established with the local mobility anchor with
      IPv4 or IPv6 transport and using any of the supported
      encapsulation mode, as per [RFC-5213] or as per this specification
      when using IPv4 transport, MUST be enabled to carry IPv4 traffic.

   o  The mobile access gateway MUST set up the route for forwarding the
      IPv4 packets received from the mobile node through the conceptual bi-
      directional tunnel set up for that mobile node.

3.2.3.3.  Binding Re-Registration and De-Registrations

   When sending a Proxy Binding Update List entry
   data structure needs to either for extending the lifetime
   of a mobility session or for de-registering the mobility session, the
   respective considerations from [RFC-5213] MUST be extended with applied.  However,
   the following additional
   fields. considerations MUST be applied.

   o  The  There MUST be an IPv4 home address Home Address option for each of the attached mobile node.  This is
      acquired from the mobile node's local assigned
      IPv4 home address(es) for that mobility anchor through the
      received Proxy Binding Acknowledgment message. session.  The IPv4 home address parameter also includes
      and the corresponding subnet mask.

   o  The IPv4 default-router prefix length fields in the option MUST be set to that
      specific address of and its prefix length.  The (P) flag in the mobile node.  This is
      acquired from
      option MUST be set to 0.

   o  The Home Network Prefix option(s) MUST NOT be present if the mobile node's local mobility anchor through same
      option(s) was not present in the
      received initial Proxy Binding Acknowledgment messages.

3.2.2.  Signaling Considerations

   All the Update
      message.  Otherwise considerations from Section 6.9 of [ID-PMIP6] apply here.
   However, the following additional considerations [RFC-5213] with respect to
      this option MUST be applied.

3.2.4.  Routing Considerations for the Mobile Node Attachment and Initial Binding Registration: Access Gateway

   o  After detecting  On receiving a new packet from the bi-directional tunnel established
      with the mobile node on its access link, node's local mobility anchor, the mobile access
      gateway must identify MUST remove the mobile node and acquire its MN-
      Identifier.  If it determines that outer header before forwarding the IPv4 home address mobility
      service needs packet
      to the mobile node.

   o  Considerations from Section 6.10.3 of [RFC-5213] MUST be offered to applied
      with respect the local routing and on the use of
      EnableMAGLocalRouting flag.

   o  On receiving a packet from a mobile node [RYUJI by checking connected to its access
      link, the policy profile], it packet MUST send a Proxy Binding Update message
      for the IPv4 home address be forwarded to the local mobility anchor
      through the bi-directional tunnel established with the local
      mobility anchor.  The
      message MUST include the IPv4 Home Address option, defined encapsulation considerations specified 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 3.1.3 MUST be applied.

3.3.  Mobility Options and Status Codes

   For supporting IPv4 home address support for mobility feature, this specification
   defines the mobile node.  [RYUJI The mobile access
      gateway contain either an following new options and Status Codes.

3.3.1.  IPv4 Home Default-Router Address Option or a Home
      Network Prefix

   A new option, or both, depending on IPv4 Default-Router Address Option is defined for using
   it in the mobile node's
      type.]

   o  If Proxy Binding Acknowledgment message sent by the local
   mobility anchor to the mobile access gateway learns gateway.  This option can be
   used for sending the mobile node's IPv4 home
      network prefix or the default-router address.

   The IPv4 home address either from its policy
      store or from Default-Router Address option has an alignment requirement
   of 4n.  Its format is as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |   Length      |         Reserved (R)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  IPv4 Default Router Address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type
           <IANA>

       Length

           8-bit unsigned integer indicating the DHCP messages exchanged between length of the option in
           octets, excluding the type and length fields. This field MUST
           be set to 6.

       Reserved (R)

           This 8-bit field is unused for now.  The value MUST be
           initialized to 0 by the mobile node sender and MUST be ignored by the DHCP server,
           receiver.

       IPv4 Default-Router Address

           A four-byte field containing the mobile access gateway can specify the
      same in the node's default router
           address.

               Figure 3: IPv4 Home Default-Router Address option Option

3.3.2.  Status Codes

   This document defines the following new Status values for requesting use in the local
      mobility anchor to allocate that address or
   Proxy Binding Acknowledgement message.  These values are to allocate an address be
   allocated from the specified home network prefix.  If the specified value is
      0.0.0.0, then the local mobility anchor will consider this same numbering space, 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 6.1.8
   of [ID-DSMIP6].  The [RFC-3775].

   NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA
      Mobile node not authorized for the requesting IPv4 Home home address

3.4.  Supporting DHCP Based Address option is sent with a
      proxy binding update message.  The format of the proxy binding
      update is slightly different from the one of [ID-DSMIP6].  In [ID-
      DSMIP6], the source Configuration

   This section explains how DHCP based address of IPv6 header must configuration support
   can be enabled for a home address
      of the mobile terminal.  However, since node in a Proxy Mobile IPv6 supports
      also IPv4-only nodes, IPv6 home address is not always available on domain.  It
   explains the terminal.  In addition to this, protocol operation, supported DHCP server deployment
   configurations and the originator protocol interactions between DHCP agents and
   mobility entities in each of this proxy
      binding update is not the supported configurations.

   This specification supports the following two DHCP deployment
   configurations.

   o  DHCP relay agent co-located with the mobile terminal, but access gateway.

   o  DHCP server co-located in the mobile access gateway.

   The following are the configuration requirements:

   o  The DHCP server or the DHCP relay agent configured on the mobile
      access gateway cannot send is required to have an IPv4 address for exchanging
      the proxy binding
      update DHCP messages with the mobile node's home node.  This address because of security
      reasons (IPsec and ingress filtering).  Therefore, in this
      specification, can either
      the mobile access gateway's care-of address (Proxy-
      CoA) is used in IPv4 Proxy Care-of Address or the IPv6 source mobile node's default-router
      address field.

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

   Receiving Binding Acknowledgement Message:

   o  If the received Proxy Binding Acknowledgement message has neither
      an IPv4 Address Acknowledgement option or a Home Network Prefix
      option present, local mobility anchor.  Optionally, all
      the DHCP servers co-located with the mobile access gateway MUST ignore gateways in the
      Proxy
      Binding Acknowledgement and MUST NOT enable routing Mobile IPv6 domain can be configured with a fixed IPv4
      address.  This can be a virtual address used only for the mobile
      node's IPv4 Home Address or IPv6 home DHCP
      protocol communication on any of the access links.  This address traffic.  However,
      if there is an IPv4 Home Address Acknowledgment option present
      will be the server identifier in the reply, DHCP messages.

   o  The DHCP server identifies the option MUST be processed as per a DHCP client either from the rules specified
      client identifier or the client hardware address (chaddr).  A
      mobile node in Dual Stack a Proxy Mobile IPv6 specification [ID-DSMIP6].

   o  If domain may present any of these
      identifiers to the received Proxy Binding Acknowledgement message has DHCP server as long as the
      Status field value in identifier remains
      the IPv4 Address Acknowledgement Option set
      to a value that indicates that same through out the request was rejected by mobile node's attachment in that Proxy
      Mobile IPv6 domain.  If the
      local mobility anchor, client hardware address is used as the
      identifier and if the mobile access gateway MUST NOT enable
      IPv4 support for node performs an handoff between two
      interfaces, this hardware identifier will change and the DHCP
      server will not be able to identify the mobile node.  However, if there  Thus, it is an IPv6
      Home Network Prefix option in the Proxy Binding Acknowledgement
      message and
      recommended that the Status field DHCP client in the message mobile node is set configured
      to use a value 0
      (Proxy Binding Update accepted), stable client identifier that does not change during the
      active life of that DHCP session.

   o  All the DHCP servers co-located with the mobile access gateway MUST
      enable gateways in
      a Proxy Mobile IPv6 support for domain SHOULD be configured with the mobile node.

   o  If same set
      of DHCP option values (Ex: DNS Server, SIP Server ..etc.).

3.4.1.  DHCP Server co-located with the received Proxy Binding Acknowledgement message has Mobile Access Gateway

   Figure 4 shows the
      Status field value set to 0 (Proxy Binding Update accepted), operational sequence of the home address
   assignment when a DHCP server is co-located with the mobile access gateway MUST update a
   gateways.

     MN   MAG(DHCP-S)  LMA
      |------>|        |    1. DHCPDISCOVERY
      |       |------->|    2. Proxy Binding Update List entry *
      |       |<-------|    3. Proxy Binding Acknowledgement (IPv4HoA)
      |       |========|    4. Tunnel/Route Setup*
      |<------|        |    5. DHCPOFFER  (IPv4 HoA)
      |------>|        |    6. DHCPREQUEST (IPv4 HoA)
      |<------|        |    7. DHCPACK
      |       |        |
      * DHCP discovery (no.1) and
      must setup a tunnel to the local mobility anchor PBU (no.2) are operated in parallel.
      * Tunnel/Route setup(no.4) and must also add
      a default route over the tunnel for all DHCPOFFER/REQUEST/ACK(no.5-7)
        are processed in parallel.

    Figure 4: Overview of DHCP Server located at Mobile Access Gateway

   Initial IPv4 Home Address Assignment:

   o  If the mobile node's IPv4
      traffic.  The encapsulation mode for the bi-directional tunnel set node attached to IPv4-In-IPv6 mode.  The considerations from Section 6.10 [ID-
      PMIP6] apply.

   Extending Binding Lifetime:

   o  For extending the binding lifetime of access link sends a currently registered
      DHCPDISCOVERY message, the DHCP server co-located with the mobile node ,
      access gateway will trigger the mobile access gateway MUST send a Proxy Binding
      Update message to complete
      the local mobility anchor with a non zero
      lifetime value.  The message MUST contain Proxy Mobile IPv6 signaling.  This is the IPv4 Home Address
      option with required interaction
      between these two protocols.  If the value set mobile access gateway is
      unable to complete the currently registered Proxy Mobile IPv6 signaling or if the local
      mobility anchor does not assign an IPv4 home address value.  Additionally, if there is a registered IPv6 home
      network prefix for the mobile node for
      node, the connected interface on
      that mobile access link, both the options, Home Network Prefix option and
      the IPv4 Home Address option gateway MUST be present and tear down the point-to-point
      link shared with the values
      set to mobile node.

   o  After a successful completion of the respective registered values. Proxy Mobile Node Detachment IPv6 signaling
      and Binding De-Registration:

   o  As specified in Section 6.9.1 [ID-PMIP6], at any point in time,
      when acquiring the mobile access gateway detects that node's IPv4 home address assigned by the
      local mobility anchor, the DHCP server on the mobile node has
      moved away from its access link, it SHOULD
      gateway will send a Proxy Binding
      Update DHCP offer message to the local mobility anchor with the lifetime
      value set to zero. mobile node.  The message MUST contain
      offered address will the mobile node's IPv4 Home Address
      option with home address, assigned
      by the value local mobility anchor.  The 'siaddr' field of the DHCPOFFER
      message will be set to the currently registered IPv4 home mobile node's default-router address value.  Additionally, if there is a registered IPv6 home
      network prefix or
      to the globally fixed address used for all DHCP servers.  The
      DHCPOFFER message will be unicasted to the mobile node for node.

   o  If the connected interface on
      that access link, both mobile node sends the options, Home Network Prefix option and DHCPREQUEST message, the DHCP server
      will send DHCPACK message, as per [RFC-2131].

   IPv4 Home Address option MUST be present and Renewal with the values
      set to the respective registered values.

   Constructing DHCP server (No Handoff):

   o  When the Proxy Binding Update Message:

   The mobile access gateway when sending DHCP client goes into the Proxy Binding Update
   request to DHCP-RENEWING-STATE [RFC-2131],
      it simply unicasts DHCPREQUEST message including the local mobility anchor for requesting assigned IPv4
      home address
   mobility support MUST construct the message with in the following
   considerations.

   o 'requested IPv4 address' option.  The message MUST be constructed as
      DHCPREQUEST is sent to the address specified in Section 6.9 'server
      identifier' field of
      [ID-PMIP6].  However, when sending the messages over IPv4
      transport, additional considerations from Section 4.0 MUST be
      applied. previously received DHCPOFFER and DHCPACK
      messages.

   o  The DHCP server will send a DHCPACK to the mobile node.

   IPv4 Home Address option [ID-DSMIP6] MUST be present. Renewal with the different DHCP server (After
   Handoff):

   1. The use of Virtual DHCP server address value MAY be set 0.0.0.0
     MN   oMAG(DHCP-S) nMAG(DHCP-S)
      |       :        |
    RENEW------------->|    1. DHCPREQUEST (IPv4 HoA)
    BOUND<-------------|    2. DHCPACK or DHCPNACK
      |       :        |

   2. The use of FORCERENEW [RFC3-203]
     MN   oMAG(DHCP-S) nMAG(DHCP-S)
      |       :        |
    RENEW------------->|    1. DHCPREQUEST*a (IPv4 HoA)
      |<---------------|    2. FORCERENEW
      |--------------->|    3. DHCPREQUEST*b (IPv4 HoA)
    BOUND<-------------|    4. DHCPACK or DHCPNACK
      |       :        |
                            *a DHCPREQUEST sent to a specific value.

   DHCP Messages from the mobile node: oMAG
                            *b DHCPREQUEST sent to nMAG

   3. The operations use of Individual DHCP are almost same for both scenarios listed in
   Section 3.1.  There is one special operation for server address renewing
   operation when a mobile access gateway is
     MN   oMAG(DHCP-S) nMAG(DHCP-S)
      |       :        |
    RENEW------------->|    1. DHCPREQUEST (IPv4 HoA)
      |       :        |     (discarding & timeout)
    REBINDING--------->|    2. DHCPDISCOVERY
      |<---------------|    3. DHCPOFFER  (IPv4 HoA)
      |--------------->|    4. DHCPREQUEST(IPv4 HoA)
    BOUND<-------------|    5. DHCPACK    (IPv4 HoA)
      |       :        |

            Figure 5: Renewing Address to different DHCP server

   o  When the DHCP client goes into the DHCP-RENEWING-STATE [RFC-2131],
      it directly unicasts DHCPREQUEST message to the DHCP server.

   o  When a  If
      the mobile node attached moves and attaches to an a new mobile access link and attempts gateway,
      it needs to
      obtain an IPv4 address configuration, using update the DHCP or other
      procedures, it will get an IPv4 server address as an to the new one (i.e.
      the address of the currently attached mobile access gateway).
      Thus, one of following operations is required.

   o  If the IPv4 home virtual DHCP address
      from its home subnet as discussed in Section 3.1.  The is used, the DHCPREQUEST for
      renewing address is received by the mobile access gateway on to which
      the access link where mobile node is attached,
      will register currently attached.  The mobile access gateway
      SHOULD reply DHCPACK or DHCPNACK depending on the correctness of
      the requesting IPv4 home address with the local mobility anchor
      using in the IPv4 Home Address option, defined DHCPREQUEST as shown in Section 3.1.1 of
      [ID-DSMIP6].  The
      Figure 5-1).

   o  If the IPv4 Home Address option virtual DHCP address is sent with a proxy
      binding update.

   o  When a not used, the mobile node attempts to obtain an IPv4 home
      reconfigures the DHCP server address by
      using DHCP, whenever it changes the
      attached mobile access gateway.

      *  If a mobile access gateway SHOULD complete the proxy
      binding registration before starting receives any DHCP operation.  This is
      necessary for the messages unicasted
         to a different mobile access gateway to obtain all the
      information required for DHCP operation from the local mobility
      anchor.

   o  The mobile access gateway node, it
         SHOULD send a proxy binding update with
      0.0.0.0 unicast FORCERENEW message [RFC-3203] to the mobile node
         as shown in Figure 5-2).  In the FORCERENEW, the IPv4 Home Address 'server
         identifier' field of MUST be overwritten by the IPv4 home address option [ID-DSMIP6] and retrieve of
         the assigned IPv4 home
      address from current mobile access gateway so that the client can update
         the DHCP server address.

      *  If the local mobility anchor.  The IPv4 home virtual DHCP address
      assigned by the local mobility anchor is offered to not used and the FORCERENEW
         [RFC-3203] is not supported at the mobile
      node by DHCP.

   o  When a mobile node changes its attached mobile access gateway, the
      new
         mobile access gateway MUST sends a proxy binding update with
      the IPv4 home address option.  If SHOULD discard any DHCPREQUEST message
         sent not to the new mobile access gateway
      know the assigned IPv4 home address, for example by context
      transfer mechanism or policy profile, it SHOULD include itself, so that the
      address in
         mobile node should go into the IPv4 Home Address field.  Otherwise, it uses
      0.0.0.0 DHCP-REBINDING-STATE and obtains the assigned IPv4 home address of
         broadcast DHCPDISCOVERY without server identifier as shown in
         Figure 5-3).

   Additional Operation:

   o  At an point the mobile
      node from access gateway fails to extend the binding
      lifetime with the local mobility anchor, again.

   o  Except for it MUST send an
      unsolicited DHCPNACK to the mobile node's bootstrap, DHCP runs independently to node.  It MUST also tear down
      the proxy binding registration, for instance, for renewing point-to-point link shared with the
      assigned IPv4 home address.  It is not necessary to run DHCP
      whenever a mobile node changes its attached node.

3.4.2.  DHCP Relay Agent co-located with the Mobile Access Gateway

   A DHCP relay is co-located with each mobile access gateway.  A DHCP client renew
   server is located somewhere in the address according to Proxy Mobile IPv6 domain or is co-
   located with the local mobility anchor.  Figure 6 are the sequence of
   IPv4 home address lifetime,
      etc.  However, whenever assignment using DHCP Relay.

   MN   MAG(DHCP-R)  LMA DHCP-S
    |       |------->|      | 1. Proxy Binding Update *
    |       |<-------|      | 2. Proxy Binding Acknowledgement (IPv4HoA)
    |       |========|      | 3. Tunnel/Route Setup*
    |------>|-------------->| 4. DHCPDISCOVERY (IPv4HoA) via DHCP-R
    |<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R
    |------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R
    |<------|<--------------| 7. DHCPACK via DHCP-R
    |       |        |
    * Tunnel/Route setup(no.3) and DHCPOFFER/REQUEST/ACK (no.4-7)
      are processed in parallel.

   Figure 6: Overview of the DHCP relay located at mobile access gateway

   Initial IPv4 Home Address Assignment:

   o  When the mobile access gateway receives a DHCPDISCOVERY message
      from a mobile node renews node, it MUST check whether it has already obtained
      the IPv4 home address
      by DHCP (DHCP RENEWING STATE [RFC-2131]), for the mobile access
      gateway SHOULD send a proxy binding update to node from the local mobility
      anchor regardless of the mobile node's assigned address changes.
      anchor.

   o  When a mobile node gets  If the 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, is not yet assigned by the DHCP client unicasts DHCP renew to local mobility
      anchor, the mobile access gateway, when the DHCP client goes into the DHCP
      RENEWING state [RFC-2131].  However, when the mobile node
      handovers to gateway MUST send a new mobile access gateway, Proxy Binding Update
      for that.

   o  If the mobile node does IPv4 home address is not
      know the link change and the DHCP client would unicast DHCP
      request assigned to the previous mobile access gateway whose IP address was
      acquired from DHCP offer.  The DHCP client in the mobile node
      needs to reconfigure its by the
      local configuration parameters.  The
      mobile access gateway SHOULD discard any DHCP request message that
      does not belong mobility anchor due to administrative policy or resource
      limitation, it MUST discard the mobile access gateway itself, so that DHCPDISCOVERY messages from the
      mobile node should go into node.

   o  Otherwise, it MUST add the DHCP REBINDING state and broadcast
      DHCP discovery message 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 relay agent information option
      [RFC-3046] to be extended with the following additional
   parameter, as specified in [ID-DSMIP6] specification and is presented
   here for convenience.

   o DHCPDISCOVERY message.  The assigned IPv4 home
      address (32-bit full address) is included in the Agent Remote ID
      Sub-option of the DHCP relay agent information option.  This sub-
      option is used as a hint of address assignment of the registered DHCP server.

   o  When the mobile node.  The access gateway receives the DHCPOFFER from the
      DHCP server, it MUST verify whether the DHCP server offers the
      correct IPv4 home address value may have been statically configured which is indicated in the Agent Remote
      ID Sub-option of the DHCPDISOCVERY.  If the DHCP server offers the
      different address from the expected address, the mobile node's policy profile, it MAY have been assigned by access
      gateway MUST drop the DHCPOFFER.

   o  After the successful relaying the DHCPOFFER, the mobile access
      gateway acts as a regular DHCP
      server, or it relay agent as [RFC-2131].

   o  As shown in Figure 6, the DHCP messages MAY have been dynamically allocated be sent across an
      administrative boundaries.  The operators MUST ensure to secure
      these messages.  All the DHCP messages relayed by the mobile
      access gateway can be tunneled over the local mobility anchor.

3.3.2.  Signaling Considerations

   All anchor if
      needed.  Alternatively, if the considerations explained networks in Section 5.3 [ID-PMIP6] apply
   here. the Proxy Mobile IPv6
      domain are secured enough, the mobile access gateway just relays
      the DHCP messages to the server without the tunnel.  For supporting IPv4 home address mobility feature, doing
      this, all the
   following additional considerations mobile access gateway MUST have the route toward the
      DHCP server.  More remarks can be applied.

   Processing Binding Registrations:

   o  If there is an found in Section 7.

   IPv4 Home Address option present in Renewal to the request,
      but if there is no Home Network Prefix option present in same DHCP server: (No Hanover)

   o  When the
      request, DHCP client goes into the local mobility anchor MUST NOT reject DHCP-RENEWING-STATE [RFC-2131],
      it directly unicasts DHCPREQUEST message to the request as
      specified in [ID-PMIP6].  At least DHCP server.  The
      DHCP relay agent cannot receive the DHCPREQUEST for renewing
      addresses.  Thus, one of these two options MUST
      be present.  However, if both following operations is required.

      *  The DHCP relay agent SHOULD intercept all the options are not present, DHCP packets
         regardless of the
      local mobility anchor MUST reject destination address.  Since the request link between
         a mobile node 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 access gateway is the identifier from point-to-point
         link, it is possible to check the Mobile
      Node Identifier Option [RFC-4283] present in DHCP packets at the Proxy Binding
      Update request and MUST apply multihoming considerations specified
      in Section 5.4 [ID-PMIP6] and from this section for performing interface
         by enabling the
      Binding Cache entry existence test.

   o  If there promiscuous mode.

      *  The cost of packets monitoring is no existing Binding Cache entry that matches not negligible.  Therefore,
         The DHCP relay agent MAY use the
      request, DHCP Server Identifier
         Override Sub-option [RFC-5107] to intercept DHCPREQUESTs for
         the local mobility anchor MUST consider this request as
      an initial binding registration request.  If address renewal.  The DHCP client uses the entry exists, DHCP server
         address which is overridden by the
      local mobility anchor MUST consider this request DHCP relay agent address as
         a binding re-
      registration request.

   o  The proxy care-of destination address MUST be retrieved from of DHCPREQUEST.  The DHCP Server
         Identifier Override Sub-option is recommended only when the source
         Virtual DHCP address field of is configured on all the proxy binding update message.

   o  If mobile access
         gateways.  Otherwise, the IPv4 Home Address option present in DHCP relay agent address is changed
         when the Proxy Binding
      Update request has mobile node changes the value of 0.0.0.0, attached mobile access
         gateway.  As a result, the local mobility anchor DHCP relay agent MUST allocate an IPv4 home address for monitor DHCP
         packets by force as described above.

   o  Once the DHCP relay agent intercepts the DHCPREQUEST from the
      mobile node and send a
      Proxy Binding Acknowledgement message and including node, it MUST verify the requesting IPv4
      Address Acknowledgement option, defined home address
      stored in Section 3.2.1 of [ID-
      DSMIP6], containing the allocated address value. DHCPREQUEST message.  The specific
      details on how verification is operated
      by checking it with the local mobility anchor allocates binding update list for the mobile node.
      If the requesting IPv4 home address is outside not registered to the scope of this document.  The local
      mobility
      anchor MUST ensure anchor, the allocated prefix is not in use by any other mobile node. access gateway MUST NOT relay the
      DHCPREQUEST and MUST discard it.

   o  If the local mobility anchor address verification is unable successfully completed, the DHCP
      relay agent SHOULD forward the DHCPREQUEST to allocate an IPv4 home
      address for the DHCP server.

   Additional Operations:

   o  If the mobile node, it MUST reject access gateway sends Proxy Binding Update for the request
      IPv4 home address and send a receives the unsuccessful Proxy Binding
      Acknowledgement message with Status field set to 130
      (Insufficient resources).

   o  Upon accepting the request, (by indicating the local mobility anchor error codes), it MUST create
      a Binding Cache entry send
      unsolicited DHCPNACK for the invalid IPv4 home address to the
      mobile node.  It must set the fields
      in  XXXX

4.  IPv4 Transport Support

   The Proxy Mobile IPv6 specification [RFC-5213] requires the Binding Cache entry to signaling
   messages exchanged between the accepted values for that
      binding.  It MUST also establish a bi-directional tunnel to local mobility anchor and the mobile
   access gateway, as described in [RFC-2473].  Considerations
      from Section 5.6 [ID-PMIP6] MUST gateway to be applied. over an IPv6 transport.  The extensions defined
   in this section allow the exchange of signaling messages over an IPv4
   transport when the local mobility anchor MUST add and the mobile access
   gateway are separated by an IPv4 host route for that allocated network and are reachable using only
   IPv4 addresses.

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

                     Figure 7: 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 Transport Network

   When the local mobility anchor to perform the Binding Cache
      entry existence test for identifying and the mobility session, by mobile access gateway are
   configured and reachable using only IPv4 addresses, the mobile access
   gateway serving a mobile node identifier, interface identifier and can potentially send the
      Home Network Prefix values.  When using an signaling
   messages over IPv4 transport and register its IPv4 home address
      value, instead of as the IPv6 home network prefix for matching
   care-of address in the mobile node's Binding Cache entry, all those considerations equally apply for
      the entry.  An IPv4 home address as well.

   o  If there is an Home Network Prefix option present in
   tunnel (with any of the Proxy
      Binding Update request and with a NON_ZERO value, supported encapsulation modes) can be used
   for tunneling the mobile node's data traffic.  The following are the
   key aspects of this feature.

   o  The local mobility anchor MUST use this parameter in combination with and the mobile node identifier access gateway are both
      configured and interface identifier for matching the
      Binding Cache entry, just reachable using only an IPv4 address.
      Additionally, both these entities are also IPv6 enabled and have
      configured IPv6 addresses on its interfaces, as specified in Section 5.4 [ID-PMIP6].
      For all other cases, the local mobility anchor MUST use the [RFC-
      5213], but are reachable only over an IPv4
      home address parameter transport.

   o  The mobile access gateway can be potentially in combination a private IPv4
      network behind a NAT [RFC-3022] device, with a private IPv4
      address configured on its egress interface.  However, the mobile node
      identifier local
      mobility anchor must not be behind a NAT and interface identifier for matching the Binding Cache
      entry, as specified in Section 5.4 [ID-PMIP6].

   Constructing the Proxy Binding Acknowledgement Message: must be using a
      globally routable IPv4 address.

   o  The Proxy Mobile IPv6 signaling messages exchanged between the
      local mobility anchor when sending the Proxy Binding
      Acknowledgement message to and the mobile access gateway MUST
      construct for
      negotiating the message IPv4 transport will be encapsulated and carried as
      IPv4 packets.  However, these signaling messages are fundamentally
      IPv6 messages using the mobility header and the related semantics
      as specified in base Proxy Mobile IPv6 base specification [ID-PMIP6].  However, the following considerations
      MUST be applied.

   o  The IPv4 Address Acknowledgement option MUST be present in the
      Proxy Binding Acknowledgement message.

      1.  If the Status field is set to [RFC-5213],
      but carried as a value greater than or equal to
          128, i.e., if the binding request is rejected, then the IPv4
          home address value payload in the an IPv4 Address Acknowledgement option
          MUST packet (IPv4-UDP encapsulation
      mode).

   o  The mobile node can be set to ALL_ZERO value.

      2.  For all other cases, the an IPv6, IPv4 home address value in or a dual IPv4/IPv6 node and
      the IPv4
          Address Acknowledgement option MUST be set transport support specified in this section is agnostic
      to the allocated
          IPv4 home type of address value for that mobility session.

3.3.3.  Routing Considerations

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

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

   o  When  The IPv4 tunnel established between the local mobility anchor is serving a and
      the mobile node, it MUST access gateway (with any of the supported encapsulation
      modes over IPv4 transport) will be able to receive packets that are sent to used for carrying 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 and IPv6 traffic.  The supported encapsulation modes
      for
      the carrying mobile node's IPv4 home network prefix or for IPv6 packets when using IPv4
      transport are as shown below.

      *  IPv4

      *  IPv4-UDP (Payload packet carried in an aggregated
      prefix with a larger scope.  This essentially enables IPv4 routers packet with UDP
         header)

      *  IPv4-UDP-TLV (Payload packet carried in that network to detect the local mobility anchor as the last-
      hop router for that an IPv4 prefix.

   Forwarding Packets packet with UDP
         and TLV header.  Refer to the Mobile Node:

   o  On receiving a [ID-DSMIP6]).

      *  IPv4-UDP-ESP (Payload packet carried in an IPv4 packet from a correspondent node with UDP
         and ESP headers.  Refer to [RFC-3948].

4.1.  Local Mobility Anchor Considerations

4.1.1.  Extensions to Binding Cache Entry

   For supporting this feature, the
      destination address matching a mobile node's IPv4 home address, conceptual Binding Cache entry data
   structure maintained by the local mobility anchor [RFC-5213] MUST forward the packet through be
   extended with the bi-
      directional tunnel setup for that mobile node. following additional parameters.

   o  The format IPv4 address of the
      tunneled packet mobile access gateway.  This 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 4: Tunneled Packets from LMA to MAG

   Forwarding Packets Sent by the Mobile Node:

   o  All
      address configured on the reverse tunneled packets egress interface of the mobile access
      gateway that sent the local mobility anchor
      receives Proxy Binding Update message.  This address
      can be obtained from the mobile access gateway, after removing IPv4 Care-of Address option, present in
      the received Proxy Binding Update message.  If the tunnel
      header option was not
      present in the request, this field MUST be routed set to the destination specified in source
      address of the inner IPv4 packet header.  These routed packets will have header of the source
      address received Proxy Binding Update
      message.  However, if the received Proxy Binding Update message is
      not sent as an IPv4 packet, this field MUST be set to the mobile node's IPv4 home address.

3.4.  Mobility Options

   For supporting ALL_ZERO
      value.

   o  The IPv4 home NAT translated address mobility feature, this specification
   defines of the following new option.

3.4.1.  IPv4 Default Router Address Option

   A new option, IPv4 Default Router Address Option mobile access gateway.  If
      the mobile access gateway is defined for using
   it in not behind a NAT [RFC-3022], this
      address will be the Proxy Binding Acknowledgment message sent by same as the local
   mobility anchor to address configured on the egress
      interface of the mobile access gateway.  This option address can be
   used for sending
      obtained from the mobile node's IPv4 default router address.

   The IPv4 Default Router Address option has an alignment requirement header of 4n.  Its format the received Proxy Binding Update
      message.  However, if the received Proxy Binding Update message is
      not sent as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |   Length      |         Reserved (R)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | an IPv4 Default Router Address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type
           <IANA>

       Length

           8-bit unsigned integer indicating the length of packet, this field MUST be set to ALL_ZERO
      value.

4.1.2.  Extensions to Mobile Node's Policy Profile

   For supporting this feature the option mobile node's policy profile,
   specified in
           octets, excluding the type and length fields. This field Section 6.2 of [RFC-5213] MUST be set to 6.

       Reserved (R) extended with the
   following additional fields.  This 8-bit field is unused are mandatory fields of the policy
   profile required for now. supporting this feature.

   o  A flag indicating if IPv4 transport should be used.  The value MUST be
           initialized to 0 by the sender and MUST of
      this flag can be ignored by different at different mobile access gateway.
      The specific details on how this flag is maintained on a per
      mobile access gateway basis is outside the
           receiver. scope of this document.

   o  The IPv4 Default Router Address

           A four-byte field containing address of the local mobility anchor (IPv4-LMAA).

4.1.3.  Signaling Considerations

   This section provides the rules for processing the mobile node's default router
           address.

               Figure 5: IPv4 Default Router Address Option

4.  IPv4 Transport Support

   The Proxy Mobile IPv6 specification [ID-PMIP6] requires the network
   between the
   signaling messages received over IPv4 transport.  The local mobility
   anchor and MUST apply these signaling rules on the mobile access gateway to IPv4 UDP encapsulated
   Proxy Binding Update messages received on DSMIP UDP port [ID-DSMIP6].

4.1.3.1.  Processing Proxy Binding Updates

   o  If the received Proxy Binding Update message (encapsulated in IPv4
      UDP packet) is protected using IPsec ESP header, then the message
      MUST be
   an IPv6 network and authenticated as described in Section 4 of [RFC-5213].
      However, if the signaling messages exchanged between IPv4 packet is not protected using IPsec ESP
      header, then the message MUST be authenticated after removing the
      outer IPv4 UDP header.

   o  All the considerations from Section 5.3.1 of [RFC-5213] MUST be
      applied on the encapsulated Proxy Binding Update message, after
      removing the outer IPv4 UDP header.

   o  If there is an IPv4 Care-of Address present in the
   local mobility anchor and request, the mobile access gateway to
      NAT presence detection procedure specified in Section 4.1.3.3 MUST
      be over an
   IPv6 transport.  The extensions defined used for detecting the NAT in this section allow the
   exchange of signaling messages over an IPv4 transport when path.

   o  Upon accepting the request, the local mobility anchor and MUST set up
      an IPv4 bi-directional tunnel to the mobile access gateway are separated by an
   IPv4 network and gateway.  The
      tunnel endpoint addresses are reachable using an IPv4 address.

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

                     Figure 6: IPv4 Transport Network

   When and the network between IPv4-Proxy-CoA.
      The encapsulation mode MUST be determined from the local mobility anchor and below
      considerations.

      *  If the mobile
   access gateway NAT is an IPv4 network, i.e., when both these mobility
   entities are configured and reachable using an IPv4 address, detected on the
   mobile access gateway serving a mobile node can potentially register
   its IPv4 address with path, then the local mobility anchor, as encapsulation mode
         for the care-of
   address tunnel MUST be set to IPv4-UDP.  Otherwise the
         encapsulation mode MUST be set to IPv4.  However, if the (F)
         flag in the mobile node's received Proxy Binding Cache entry and can negotiate Update message is set to
         value of 1 and IPv4 transport tunnel for tunneling even if NAT is not detected, then the mobile node's data
   traffic.

   The Dual Stack Mobile IPv6 specification [ID-DSMIP6] defines protocol
   extensions to Mobile IPv6 protocol for allowing a mobile node
         encapsulation mode MUST be set to roam
   into an IPv4 network and registers an IPv4 care-of address with IPv4-UDP.

      *  If the
   home agent.  The same mechanism (T) flag in the Proxy Binding Update message is leveraged for extending IPv4
   transport support set to Proxy Mobile IPv6 protocol.
         value of 1, then the encapsulation mode MUST be set to IPv4-
         UDP-TLV.

   o  The local mobility
   options for requesting IPv4 transport support, anchor MUST send the processing logic
   and Proxy Binding
      Acknowledgement message with the on-path NAT detection logic is just Status field value set to 0
      (Proxy Binding Update Accepted).  The message MUST be constructed
      as described specified in [ID-
   DSMIP6].  The following are Section 4.1.3.2.

4.1.3.2.  Constructing the key properties of this feature.

   o Proxy Binding Acknowledgement Message

   The local mobility anchor and when sending the Proxy Binding
   Acknowledgement message to the mobile access gateway are both
      configured and reachable using MUST construct
   the message as specified in Section 5.3.6 of [RFC-5213].  However, if
   the received Proxy Binding Update message was encapsulated in an UDP
   header of an IPv4 address. packet, the following additional considerations
   MUST be applied.

   o  The configured address on the mobile access gateway can NAT Detection option [ID-DSMIP6] MUST be an IPv4
      private address and when it present only if there
      is behind a NAT translation device IPv4 Care-of Address option present in the received Proxy
      Binding Update and if the mechanism specified in Dual Stack Mobile IPv6 specification
      [ID-DSMIP6] is again leveraged for NAT detection and traversal. procedure resulted in
      detecting a NAT on path.  In all other cases, the option MUST NOT
      be present.

   o  The Proxy Mobile IPv6 signaling messages exchanged between Binding Acknowledgement message MUST be encapsulated in
      an UDP header of an IPv4 packet.

   o  The source address in the
      local mobility anchor and IPv4 header of the message MUST be set
      to the destination IPv4 address of the received request.

   o  If the mobile access gateway for
      negotiating the IPv4 transport will be encapsulated and carried as
      IPv4 packets.  However, these signaling messages are fundamentally
      IPv6 messages with the mobility header and the semantics as
      specified in base Proxy Mobile IPv6 specification [ID-PMIP6], but
      carried as payload in IPv4 packets.  Additionally, the local mobility
      options defined in Dual Stack Mobile IPv6 specification [ID-
      DSMIP6] anchor are used for negotiating
      using globally routable IPv4 transport support addresses and with if there is a
      specific encapsulation mode.

   o  The security
      associated that is based of IPv4 tunnel established between addresses, then the local mobility anchor encapsulated
      IPv4 packet (containing the IPv6 PBA) MUST be protected using
      IPsec ESP [RFC-4301] mode and additionally there is no need to
      apply IPsec ESP header on the mobile access gateway (with any of IPv6 packet.  In all other cases,
      the Proxy Binding Acknowledgement message MUST be protected using
      IPsec prior to the supported encapsulation
      modes over IPv4 transport) is used for carrying UDP encapsulation.

   o  The format of the mobile node's Proxy Binding Acknowledgement message
      encapsulated in an IPv4 UDP packet and protected using IPv6 traffic.
      security association.

            IPv4 header (src=IPv4-LMAA, dst=pbu_src_address)
               UDP header (sport=DSMIP_PORT, dport= pbu_sport)
                   /* IPv6 PBU Packet protected with ESP header */

        Figure 8: Proxy Binding Acknowledgment Message encapsulated in
                                 IPv4 header

   o  The mobile node can be format of the Proxy Binding Acknowledgement message
      encapsulated in an IPv6, IPv4 or a
      dual IPv4/IPv6 node UDP packet and the protected using IPv4 transport support specified
      security association.

            IPv4 header (src=IPv4-LMAA, dst=pbu_src_address)
               ESP Header
                  UDP header (sport=DSMIP_PORT, dport= pbu_sport)
                     /* IPv6 PBU Packet protected with no ESP header */

       Figure 9: Proxy Binding Acknowledgment encapsulated in
      this section is agnostic to the type of address mobility enabled
      for the mobile node.

4.1. IPv4 ESP
                                    header

4.1.3.3.  NAT Support Presence Detection

   When the transport network between the local mobility anchor and the
   mobile access gateway is an IPv4 network, the mobile access gateway
   MUST
   will send the Proxy Binding Update message messages encapsulated in the IPv4-UDP 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 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

4.1.4.  Routing Considerations

4.1.4.1.  Forwarding Considerations

   Forwarding Packets to incorporate the NAT detection
   mechanism of IKE Mobile Node:

   o  On receiving an IPv4 or an IPv6 packet from a correspondent node
      with DSMIPv6 in the MEXT Working Groups.  This
   documentation will follow the conclusion destination address matching any of their discussions.

   [RYUJI Private addresses MUST NOT be configured at both the mobile access
   gateways and a node's
      IPv4 or IPv6 home addresses, the local mobility anchor in the same Proxy Mobile IPv6
   domain.  At least one of Proxy Mobile IPv6's tunnel end points MUST
   have a global address.  Otherwise,
      forward the packets might not be exchanged
   in packet through the bi-directional tunnel due to NAT.]

   [RYUJI When a mobile access gateway is configured with an IPv4
   private address, it MUST NOT operate the local routing (described in
   Section 6.10.3 of [ID-PMIP6]) set up for packets destined to an IPv4 address
   assigned to a correspondent
      that mobile node.

   o  The address translation MUST
   happen before the packets are arrived at the correspondent node.  To
   ensure this, the packets MUST be sent to format of the local mobility anchor
   and routed back tunneled packet is shown below.

  IPv4 Header (src= IPv4-LMAA, dst= IPv4-Proxy-CoA)] /* Tunnel Header */
    [UDP Header (src port=DSMIPv6, dst port=Z]   /* If UDP encap nego */
      [TLV Header]                               /* If TLV negotiated */
        /* IPv6 or IPv4 Payload Packet */
               IPv6 header (src= CN, dst= MN-HOA)
                          OR
               IPv4 header (src= CN, dst= IPv4 MN-HoA)

               Figure 10: Tunneled IPv4 Packet from LMA to MAG

   o  Forwarding Packets Sent by the correspondent node.]

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 Node:

      *  All the following additional
   parameters, as specified in [ID-DSMIP6] specification reverse tunneled packets (IPv4 and is reviewed
   here for convenience.

   o  The IPv4 address registered with IPv6) that the local
         mobility anchor as receives from the mobile node's care-of address.

4.2.2.  Signaling Considerations

   All access gateway, after
         removing the considerations as explained in Section 6.11 of tunnel header (i.e., 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 outer IPv4 only network, header along
         with the mobile access gateway UDP and TLV header, if negotiated) MUST have an IPv4 address at the visiting network.  In addition be routed to
      that, the mobile access gateway MUST obtain an IPv6 address
      configured for
         the Proxy Mobile IPv6 operation.  Even if destination specified in the
      mobile access gateway does not inner packet header.  These
         routed packets will have connectivity to the IPv6
      network, it MUST configure with an IPv6 source address for sending the
      proxy binding registration field set 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. node's home address.

4.1.4.2.  ECN Considerations

   The processing logic ECN considerations specified in Section 5.6.3 of [RFC-5213] apply
   for handling the
      NAT detection IPv4 transport tunnels as well.  The mobility agents at the mobile node is applicable to the mobile
      access gateway
   tunnel entry and exit points MUST handle ECN information as described in Section 4.1.

   o  An example of proxy binding update sent by mobile access gateway
      is shown specified
   in Figure 7. that document.

4.1.4.3.  Bi-Directional Tunnel Management

   The source address Tunnel Management considerations specified in section 5.6.1 of
   [RFC-5213] apply for the inner IPv6 header
      MUST set to IPv4 transport tunnels as well, with just
   one difference that the IPv6 address assigned encapsulation mode is different.

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 maintained by the mobile access gateway
      and the destination address [RFC-5213]
   MUST be extended with 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. following additional parameters.

   o  The source IPv4 address of the outer packet MUST be the IPv4-Proxy-CoA
      and the destination MUST be the local mobility anchor's IPv4 anchor.  This address (IPv4-LMAA).

   o  The IPv4-Proxy-CoA MUST can
      be set in obtained from the IPv4 Care-of Address option
      defined in section 3.1.2 of [ID-DSMIP6]. mobile node's policy profile.

   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 IPv4 address of 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 gateway.  This is the proxy binding update message.
      The format of
      address configured on 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 egress interface of the mobile access
      gateway and is registered with the mobile node's local mobility
      anchor are pre-established.

   Constructing as the Proxy Binding Update Message:

   o  For requesting IPv4 transport support, Proxy-CoA.  However, if the mobile access
      gateway
      when sending is in a private IPv4 network and behind a NAT, the Proxy Binding Update request to address
      that is registered with the mobile node's local mobility anchor from an IPv4 networks MUST construct is
      the message
      as specified below. NAT translated public IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
            UDP header
               IPv6 header (src=Proxy-CoA, dst=LMAA)
                  Mobility header
                     -BU (P flag is set. F/T flags are optional)
                         Mobility Options
                            - address.

4.2.2.  Signaling Considerations

   The IPv4 Care-of Address option(Mandatory)
                            -
                            - All mobile access gateway when sending a Proxy Binding Update message
   to the options as required by [ID-PMIP6]
                            - or local mobility anchor MUST construct the message as required by any extension documents
                            -

       Figure 7: specified
   in Section 6.9.1.5.  However, if the mobile access gateway is in an
   IPv4-only access network, the following additional considerations
   MUST be applied.

   o  The Proxy Binding Update Message Format for message MUST be encapsulated in an UDP
      header of an IPv4 Transport
                                   Support
   o packet.

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

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

   Receiving Binding Registration Reply: Section 4.2.3.

   o  After receiving  When sending a Proxy Binding Acknowledgment message
      encapsulated in an IPv4 packet, the mobile access gateway MUST
      verify the Proxy Binding Acknowledgment according to for extending the Section
      4.3 lifetime of Dual Stack Mobile IPv6 specification [ID-DSMIP6].

   o  If the Status field indicates Success, the mobile access gateway
      MUST setup
      a tunnel to currently existing mobility session or for de-registering the local
      mobility anchor and add a default
      route over session, the tunnel for all Proxy Binding Update message MUST be
      constructed as the mobile node's traffic. initial request.

   Receiving Proxy Binding Acknowledgement

   o  If the NAT received Proxy Binding Acknowledgement message
      (encapsulated in IPv4 UDP packet) is available and protected using IPsec ESP
      header, then the NAT detection option is presented message MUST be authenticated as described in
      Section 4 of [RFC-5213].  However, if the Proxy Binding Acknowledgment, IPv4 packet is not
      protected using IPsec ESP header, then the mobile access gateway message MUST use be
      authenticated after removing the outer IPv4 UDP tunnel to traverse header.

   o  All the NAT for mobile node's
      traffic and considerations from Section 6.9.1.2 of [RFC-5213] 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].
      applied on the encapsulated Proxy Binding Acknowledgement message,
      after removing the outer IPv4 UDP header.

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

   Forwarding Packets setup a bi-directional tunnel to Local Mobility Anchor

   o  On receiving any packets from the mobile node's IPv6 home address
      and/or IPv4 home address, local mobility anchor.

   o  Upon accepting the mobile access gateway tunnels request, the
      packets to local mobility anchor as shown in Figure 8.  If MUST set up
      an IPv4 bi-directional tunnel to the mobile access gateway gateway.  The
      tunnel endpoint addresses are IPv4-LMAA and the local mobility anchor agreed to use IPv4-Proxy-CoA.
      The encapsulation mode MUST be determined from the TLV header below
      considerations.

      *  If there is a NAT Detection option [ID-DSMIP6] in the received
         Proxy Binding Acknowledgement message, then the encapsulation
         mode for the UDP tunnel during the binding registration, MUST be set to IPv4-UDP.  Otherwise the TLV header
         encapsulation mode MUST be presented after set to IPv4.

      *  If the UDP header as shown (T) flag in
      Figure 9.

               IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
                   [UDP header] /*Only if NAT the Proxy Binding Acknowledgement message 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 8: 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 9: Tunneled Packets from MAG
         set to LMA using value of 1, then the TLV header

4.3.  Local Mobility Anchor Considerations

4.3.1.  Extensions encapsulation mode MUST be set to Binding Cache Entry

   For supporting this feature,
         IPv4-UDP-TLV.

4.2.2.1.  Constructing the conceptual Proxy 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. Update Message

   o  The IPv4 Care-of source address of in the attached mobile node.  In this
      specification, it can IPv4 header MUST be translated set to IPv4 Care-of address IPv4-Proxy-
      CoA of the mobile access gateway and the destination address MUST
      be set 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 anchor's IPv4-LMAA.

   o  The IPv4 and IPv6 home address traffic. Care-of Address option [ID-DSMIP6] MUST be present.  The DSMIPv6 specification
   provides
      address MUST be set to the semantics on how mobile access gateway's IPv4-Proxy-CoA.

   o  If the IPv4 tunnel needs configuration variable ForceIPv4UDPEncapsulationSupport is
      set to be negotiated
   and the detection logic value of 1, then the NAT devices.  This specification
   leverages the NAT Detection Option, defined (F) flag 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: Update
      message MUST be enabled.

   o  After accepting the registration from  If the mobile access gateway
      locating at the IPv4 only network, and the local mobility anchor MUST
      setup are
      using globally routable IPv4 addresses and if there is a tunnel to the mobile access gateway.  The tunnel security
      associated that is
      established between based of IPv4 addresses, then the encapsulated
      IPv4 packet (containing the v4-LMAA IPv6 PBU) MUST be protected using
      IPsec ESP [RFC-4301] mode and additionally there is no need to
      apply ESP header on the IPv4-Proxy-CoA IPv6 packet.  In all other cases, the
      Proxy Binding Update message MUST be protected on the IPv6 packet
      of the
      mobile access gateway. Proxy Binding Update message, prior to the IPv4
      encapsulation.

   o  If  The format of the NAT is available, Proxy Binding Update message encapsulated in an
      IPv4 UDP packet with IPsec protection on the local mobility anchor MUST use encapsulated packet:

            IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
               UDP header (sport=ANY, dport= DSMIP_PORT)
                   /* IPv6 PBU Packet protected with ESP header */

       Figure 11: Proxy Binding Update Message encapsulated in IPv4 UDP
      encapsulation for the tunnel.
                                    header

   o  If the T flag is set in  The format of the proxy binding update Proxy Binding Update message encapsulated in an
      IPv4 UDP packet and with IPsec protection on the
      TLV encapsulated
      packet:

            IPv4 header is presented, (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
               ESP Header
                  UDP header (sport=ANY, dport= DSMIP_PORT)
                     /* IPv6 PBU Packet protected with no ESP header */

       Figure 12: Proxy Binding Update Message Encapsulated with IPsec
                                  protection

4.2.2.2.  Forwarding Considerations

   Forwarding Packets Sent by the specified tunnel type must be used. Mobile Node:

   o  The local mobility anchor also setup a host routes for the  On receiving an IPv4
      home address and the or an IPv6 home address of packet from the mobile node over the
      tunnel to any
      destination, the mobile access gateway.  Any traffic that gateway MUST tunnel the packet to
      the local mobility anchor receives anchor.  The format of the tunneled packet is
      shown below.  However, considerations from a correspondent node will Section 6.10.3 of [RFC-
      5213] MUST be
      tunneled to the mobile access gateway over applied with respect the bi-directional
      tunnel local routing and then routed accordingly after removing the tunnel
      headers.  The encapsulation modes for on the bi-directional tunnel
      are as specified in Section 5.3
      use of Proxy Mobile EnableMAGLocalRouting flag.

 IPv4 Header (src= IPv4-Proxy-CoA, dst= IPv4-LMAA)] /* Tunnel Header */
    [UDP Header (src port=DSMIPv6, dst port=Z]   /* If UDP encap nego */
        [TLV Header]                             /* If TLV negotiated */
              /* IPv6 specification
      [ID-PMIP6] and as in this specification. or IPv4 Payload Packet */
              IPv6 header (src= CN, dst= MN-HOA)
                          OR
              IPv4 header (src= CN, dst= IPv4 MN-HoA)
               Figure 13: Tunneled IPv4 Packet from LMA to MAG

   o  Upon  Forwarding Packets received from the bi-directional tunnel:

   o  On receiving a Proxy Binding Update message encapsulated in an
      IPv4 packet, packet from the bi-directional tunnel established
      with the mobile node's local mobility anchor MUST send the Proxy Binding
      Acknowledgment to anchor, the mobile access gateway's IPv4-Proxy-CoA by
      using IPv4 encapsulation.

   o  If the NAT is detected, the NAT detection option
      gateway MUST be used in remove the Proxy Binding Acknowledgment.  How outer header before forwarding the packet
      to detect NAT is described
      in Section 4.1 of [ID-DSMIP6] and Section 4.1.

   Constructing the Proxy Binding Acknowledgement Message:

   o mobile node.

5.  Protocol Configuration Variables

5.1.  Local Mobility Anchor - Configuration Variables

   The proxy binding acknowledgment local mobility anchor MUST allow the following variables to be protected
   configured by IPsec ESP. the system management.  The security association configured values for IPv4 addresses of the mobile access
      gateway these
   protocol variables MUST survive server reboots and service restarts.

   AcceptIPv4UDPEncapsulationRequest

      This flag indicates whether or not the local mobility anchor are pre-established.

   o  For the
      should accept IPv4 transport support, no special mobility options are
      required.  Only when NAT UDP encapsulation support if there is detected, the NAT detection option
      MUST be present.
      detected in the path.

      The default value for this flag is set to value of 1, indicating
      that the local mobility anchor MUST construct the
      proxy binding Acknowledgement as specified enable IPv4 UDP encapsulation
      support on detecting NAT in [ID-PMIP6].

   o  An example the path.

      When the value for this flag is set to value of proxy binding acknowledgment sent by 0, the local
      mobility anchor is shown below.  The same illustration for Mobile IPv6 can
      be found in Section 4.1 of [ID-DSMIP6]. MUST NOT enable 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 encapsulation support.

5.2.  Mobile Access Gateway - Configuration Variables

   The mobile access gateway MUST allow the following variables to be
   configured by the system management.  The configured values for these
   protocol variables MUST survive server reboots and service restarts.

   RequestIPv4UDPEncapsulationSupport

      This flag indicates whether or not the mobile access gateway
      should request the mobile node's local mobility anchor for IPv4 Address Acknowledgement option
                             - Timestamp option (optional)
                             - Mobile Node Identifier Option
                             - Access Technology Type option (Mandatory)
                             - Mobile Node Interface Identifier option
                               (Optional)

                             -
      UDP encapsulation support if NAT Detection Option (Optional)

           Figure 10: Proxy Binding Acknowledgment is detected in IPv4 network

   Forwarding Packets to Mobile Access Gateway

   o  When sending any packets meant the path.

      The default value for this flag is set to a value of 0, indicating
      that the mobile node's IPv4 home
      address or IPv6 home address, access gateway MUST NOT request the mobile node's
      local mobility anchor tunnels for IPv4 UDP encapsulation support.

      When the packet value for this flag is set to value of 1, the mobile
      access gateway as shown in Figure 11. MUST request the mobile node's local mobility
      anchor for IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA)
                   [UDP header] /*Only UDP encapsulation support if NAT there is detected*/
                       union { /*following either v6 NAT detected
      in the path.

   ForceIPv4UDPEncapsulationSupport
      This flag indicates whether 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 11: Tunneled Packets from LMA to MAG
   o  If not the mobile access gateway and
      should request the mobile node's local mobility anchor agreed
      to use the TLV header for the forcing
      IPv4 UDP tunnel during the binding
      registration, encapsulation support even when NAT is not detected in
      path.

      The default value for this flag is set to value of 0, indicating
      that the TLV header mobile access gateway MUST be presented after NOT request the UDP
      header as shown in Figure 12. mobile node's
      local mobility anchor for forcing 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 12: Tunneled Packets from LMA encapsulation support
      even when NAT is not detected in path.

      When the value for this flag is set to MAG using value of 1, the TLV header

4.4.  Tunnel Management

   As specified in mobile
      access gateway MUST force the mobile node's local mobility anchor
      for IPv4 UDP encapsulation support.

      This flag is applicable only when the flag
      RequestIPv4UDPEncapsulationSupport is set to a value of 1.

5.3.  Proxy Mobile IPv6 specification, the bi-
   directional tunnel between Domain - Configuration Variables

   All the local mobile entities (local mobility anchor anchors and the mobile access gateway, is
   gateways) in 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 require IANA Action.

6.  Security Considerations domain MUST allow the following
   variables to be configured by the system management.  The security mechanisms specified configured
   values for these protocol variables MUST survive server reboots and
   service restarts.  These variables MUST be globally fixed for a given
   Proxy Mobile IPv6 protocol are
   used when using the extensions defined domain resulting in this document.

   When supporting IPv4 address assignment from a DHCP server, the same values being enforced
   on all the
   IPv4 home addresses managed mobility entities in that domain.

   FixedDHCPServerId

      This variable indicates the DHCP server must be reachable via
   local mobility anchor so id that local mobility anchor intercepts
   packets meant for an IPv4 home address and tunnels them to all the DHCP
      servers co-located with the mobile
   node via corresponding mobile access gateway.  Moreover, all gateways SHOULD
      configure in that Proxy Mobile IPv6 domain.  If this variable is
      initialized to ALL_ZERO value, it implies the DHCP
   messages between use of fixed address
      is not enabled for that Proxy Mobile IPv6 domain.

6.  IANA Considerations

   This document defines a DHCP relay and new Mobility Header option, IPv4 Default
   Router Address option.  This option is described in Section 3.3.1.
   The Type value for this option needs to be assigned from the same
   numbering space as allocated for the other mobility options, as
   defined in [RFC-3775].

   This document also defines new Binding Acknowledgement status values,
   as described in Section 3.3.2.  The status values MUST be assigned
   from the DHCP server SHOULD same number space used for Binding Acknowledgement status
   values, as defined in [RFC3775].  The allocated values for each of
   these status values must be securely
   exchanged.

   After receiving a greater than 128.

7.  Security Considerations

   All the security considerations from the base Proxy Binding Update message with an IPv4 Home
   Address Option, Mobile IPv6
   protocol [RFC-5213] apply when using the local mobility anchor MUST be able to verify that extensions defined in this
   document.  Additionally, the mobile node is authorized following security considerations need
   to use that address before setting up
   forwarding be applied.

   This document defines news mobility options for that host route.

   When supporting dynamic the IPv4 address
   Home Address assignment by DHCP and IPv4 Transport Support features.  It also from
   local mobility anchor, it should be ensured both
   uses some of the entities mobility options from DSMIPv6 specification [ID-
   DSMIP6].  These options are
   configured with different address pools, so as to avoid both entities
   do not allocate be carried in Proxy Binding Update and
   Proxy Binding Acknowledgement messages.  The required security
   mechanisms specified in the same address to different mobile nodes. base Proxy Mobile IPv6 protocol for
   protecting these signaling messages are sufficient when carrying
   these mobility options.

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

7. transport.

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

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

   Thanks to Jonne Soinnen, Julien Laganier, Zu Qiang, Premec Domagoj,
   Sammy Touati and Niklas Nuemann for their helpful review of this
   document.

10.  References

9.1.

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

   [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]
   draft-ietf-mip6-mext-nemo-v4traversal-05.txt,July 2008.

   [RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6",
   draft-ietf-netlmm-proxymip6-16.txt, RFC 5213,
   November 2007.

9.2.

10.2.  Informative References

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

   [RFC-3011] G. Waters, "The IPv4 Subnet Selection Option for DHCP",
   RFC 3011, November 2000.

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

   [RFC-3203] Y. T'Joens and C. Hublet and P. De Schrijver, "DHCP
   reconfigure extension", RFC 3203, December 2001.

   [RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack
   Mobility", RFC 4977, August 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.  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
   scenario is used in the same Proxy Mobile IPv6 domain based on
   deployment requirements.  The optional DHCP configurations for IPv4
   home address assignment are described below.

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

   o  DHCP relay is co-located with both each mobile access gateway

   [RFC-5107] R. Johnson and
      a local mobility anchor.  DHCP server is solely located behind the
      local mobility anchor in the Proxy Mobile IPv6 domain.

   The operations are same as described in Section 3.1.  Before relaying
   any DHCP messages, a mobile access gateway&#12288;SHOULD complete the
   proxy binding registration so that it learns the assigned address to
   provide the IPv4 home address hint to the DHCP server.  However, when
   DHCP relays are located at both a mobile access gateway J. Jumarasamy and a local
   mobility anchor, the DHCP relay at the local mobility anchor can
   simply insert the address hint retrieved from its local address
   management pool in the DHCP messages.  Thus, the IPv4 home address
   option [ID-DSMIP6] can be omitted from the Proxy Binding Update K. Kinnear and
   Acknowledgement messages. M. Stapp,
   "DHCP Server Identifier Override Suboption", RFC 5107, February 2008.

Authors' Addresses

   Ryuji Wakikawa
   Toyota ITC / Keio University
   Department of Environmental Information, Keio University.
   5322 Endo
   Fujisawa, Kanagawa  252-8520
   6-6-20 Akasaka, Minato-ku
   Tokyo  107-0052
   Japan

   Phone: +81-3-5561-8276
   Fax:   +81-3-5561-8292
   Email: ryuji@sfc.wide.ad.jp ryuji@jp.toyota-itc.com

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

   Email: sgundave@cisco.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

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