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

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

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on January 10, May 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

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

Table of Contents

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

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

   3.  IPv4 Home Address Mobility Support . . . . . . . . . . . . . .  7
     3.1.  IPv4 Home Address Assignment . . . . . . . . . . . . . . .  7
     3.2.  Mobile Access Gateway Considerations . . . . . . . . . . . 10
       3.2.1.  Extensions to Conceptual Data Structure Binding Update List Entry  . . . . . . . 10
       3.2.2.  Signaling Considerations . . . . . . . . .  9 . . . . . . 10
     3.3.  Local Mobility Options Anchor Considerations . . . . . . . . . . . 14
       3.3.1.  Extensions to Binding Cache Entry  . . . . . . . . . .  9
     3.4.  Mobile Access Gateway Operation 14
       3.3.2.  Signaling Considerations . . . . . . . . . . . . . .  9
     3.5.  Local Mobility Anchor Operation . 15
       3.3.3.  Routing Considerations . . . . . . . . . . . . . . . 11 . 17

   4.  IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 13 19
     4.1.  Mobility Options  NAT Detection  . . . . . . . . . . . . . . . . . . . . . 13 . 20
     4.2.  Mobile Access Gateway Considerations . . . . . . . . . . . 20
       4.2.1.  Extensions to Conceptual Data Structure Binding Update List Entry  . . . . . . . 20
       4.2.2.  Signaling Considerations . . . 13
     4.3.  NAT Detection . . . . . . . . . . . . 20
     4.3.  Local Mobility Anchor Considerations . . . . . . . . . . 14
     4.4.  Mobile Access Gateway Operation . 24
       4.3.1.  Extensions to Binding Cache Entry  . . . . . . . . . . 24
       4.3.2.  Signaling Considerations . . 14
     4.5.  Local Mobility Anchor Operation . . . . . . . . . . . . . 16
     4.6. 24
     4.4.  Tunnel Management  . . . . . . . . . . . . . . . . . . . . 18 26

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

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

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

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

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

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

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

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 the a
   mobile node, 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 the a local mobility anchor are
   both IPv4 and IPv6 enabled and further it may be an IPv4-
   only network.  It is also reasonable to expect the same mobility
   infrastructure in a Proxy Mobile IPv6 domain to provide both IPv4 and mobility to
   the mobile node's operating in IPv4, IPv6
   address or in dual mode and when
   the network between the local mobility for a anchor and the mobile node. access
   gateway is an IPv4 network.  The motivation and scope of IPv4 support
   in Mobile IPv6 is summarized in [ID-DSMIP6-PS]. [RFC-4977].

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

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

   o  IPv4 Home Address Mobility: Mobility Support: A mobile node operating in IPv4-only
      mode or in a dual-stack mode should that has IPv4
      stack enabled will be able to obtain an IPv4 home address and roam anywhere 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 transport network between the
      local mobility anchor and entities in the mobile access gateway is Proxy Mobile
      IPv6 domain will be able to exchange Proxy Mobile IPv6 signaling
      messages over an IPv4
      network transport and further the local mobility
      anchor or the mobile access gateway may be using IPv4 private
      addresses and with NAT [RFC-3022] translation devices on the path separating
      them.

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

   As specified in the Proxy Mobile IPv6 specification [ID-PMIP6], this
   specification assumes that the link between the mobile access gateway
   and the local mobility anchor is a point-to-point link.

   This specification also assumes requires that the local mobility anchor and the
   mobile access gateway are both IPv6 capable and IPv6 enabled and even
   when enabled,
   irrespective of the type of transport network between the mobile access gateway and a local
   mobility anchor is IPv4-only network. (IPv4 or IPv6),
   connecting these two entities.  The signaling protocol is
   primarily
   fundamentally based on Mobile IPv6 and hence the entities providing the
   network-based mobility management service must be IPv6 enabled. IPv6.

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

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

               Figure 1: IPv4 support for Proxy Mobile IPv6

2.  Conventions & Terminology

2.1.  Conventions

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

2.2.  Terminology

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

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

      The IPv4 Care-of Address address that is configured on the interface of the mobile
      access gateway and is the transport endpoint of the tunnel between
      a local mobility anchor and a mobile access gateway.  This address
      will be used as the source address for the signaling messages sent
      by the mobile access gateway to the local mobility anchor and will
      be the registered Care-of address in the mobile node's Binding
      Cache entry.  However, when the configured address is a private
      IPv4 address and with a NAT device in the path to the local
      mobility anchor, the care-of address as seen by the local mobility
      anchor will be the address allocated by the NAT device for the mobility
      session. that
      flow.

   IPv4 Local Mobility Anchor Address (IPv4-LMAA)

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

3.  IPv4 Home Address Mobility Support

   Using

   An IPv4 enabled mobile node when it attaches to the Proxy Mobile IPv6
   domain, the network will ensure the extensions defined in this specification, a mobile node
   operating in an IPv4-only or dual-stack mode will be able to
   obtain an IPv4 address (IPv4-MN-HoA) and will be able from its home network prefix for
   the interface attached to roam the access network in that Proxy Mobile
   IPv6 domain using that address.  Although IPv6 home address is
   always required domain.  Using the extensions defined in [ID-DSMIP6], this specification does not mandate
   IPv6 home address unless a mobile node wants specification, the IPv6 home address.
   The network will provide mobility to that
   mobile node in that entire
   domain.  And further, access gateway on the access network will ensure that exchange the
   signaling messages with the mobile node node's local mobility anchor and
   will always be able setup the required routing state for that home address.

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

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

3.1.  IPv4 Home Address Assignment

   A mobile node on attaching to an access link connected to a mobile
   access gateway, and if the network allows the mobile node for IPv4
   home address mobility service, the mobile node using any of the IPv4
   address configuration procedures, such as DHCP, DHCP [RFC-2131], IPCP or
   IKEv2 that are supported on that access link, will be able to obtain
   required information for its IPv4 home address configuration.  The IPv4 home address configuration
   required information includes the IPv4 home address, the IPv4 home
   network prefix and IPv4 home network prefix length.

   Figure 2 shows the operational sequence of the home address mobility
   support when a local mobility anchor assigns an  Any available
   IPv4 Home Address
   dynamically address configuration mechanisms can be used such as static
   configuration method specific to the access link or dynamic
   configuration from DHCP.

   When a mobile node.  All mobile access node is configured with a static IPv4 home address, the
   IPv4 home address information SHOULD be stored in the mobile node's
   policy profile.  The mobile access gateway where the mobile node
   attached obtains the static IPv4 home address from the policy
   profile.  The mobile access gateway MUST set the known IPv4 home
   prefix to the IPv4 Home Address field and the Pref field of the IPv4
   home address option [ID-DSMIP6].  This option is carried by a proxy
   binding update described in [ID-PMIP6].

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

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

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

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

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

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

   In addition to this, other address configuration mechanisms including
   static configuration methods specific to the second scenario, a DHCP relay is co-located at each mobile
   access link or dynamic
   configuration from the gateway and a DHCP server (without local mobility anchor
   involvmenet) may also be in place.  Several other assignment schems
   are listed:

   o  Static IPv4 Home Address Assignment: When a mobile node is
      configured with co-located at a static IPv4 home address, the IPv4 home address
      information MUST be stored in the mobile node's policy profile. local mobility
   anchor.  The mobile access gateway where the mobile node attached obtains learns the static IPv4 home address from
   the policy profile.  The DHCP reply and sends that information to the mobile
      access gateway MUST set node by DHCP
   offer message.  Meanwhile, it notifies the known assigned IPv4 home prefix to the IPv4
      Home Address field and the Pref field of the address
   by an IPv4 home address option [ID-DSMIP6].  This option is carried by in a proxy binding update described in [ID-PMIP6].

   o  Dynamic IPv4 Home Address Assignment from DHCP Server: If DHCP is
      used for the IPv4 home address allocation, a DHCP server and a
      DHCP relay agent on the link will ensure to the mobile node is
      assigned an address from its home network prefix. local
   mobility anchor.  In this case, the local mobility anchor does not
   allocate any address, but only deals with route setup and tunnel
   setup for the requested home address.  A DHCP relay and a mobile
      access gateway should be co-located.  Otherwise, the mobile access
      gateway MUST learn  Note that all the IPv4 home address from
   addresses managed in the DHCP reply.
      Meanwhile, it notifies the assigned IPv4 home address by server must be reachable via local
   mobility anchor so that local mobility anchor intercepts packets
   meant for an IPv4 home address option in a proxy binding update and tunnels them to the local
      mobility anchor.  Some remarks can be found in Section 6.

3.2.  Extensions to Conceptual Data Structure

   There are certain extensions defined in DSMIP specification [DSMIP6]
   for supporting IPv4 home address mobility support.  A mobile node
   via corresponding mobile access gateway.  In addition, the DHCP
   messages MAY be sent across an administrative boundaries.  The
   operators MUST ensure to secure these messages.  More remarks can
   obtain only be
   found in Section 6.  Figure 3 are the sequence of IPv4 home address by
   assignment using DHCP Relay.

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

                      Figure 3: The use of DHCP relay

3.2.  Mobile Access Gateway Considerations

3.2.1.  Extensions to Binding Update List Entry

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

   o  The IPv4 home address support.  Thus, a of the attached mobile access gateway and a local mobility agent MUST create a
   binding update list and a binding cache only for node.  The IPv4 home
      address
   assigned to a value is acquired from the mobile node.

3.3.  Mobility Options node's local mobility
      anchor through the received Proxy Binding Acknowledgment messages.

3.2.2.  Signaling Considerations

   All the considerations explained in Section 6.11 of the base Proxy
   Mobile IPv6 specification apply here.  For supporting the IPv4 home
   address mobility, mobility feature, the following options
   are required from the DSMIPv6 specification [ID-DSMIP6].

   o  IPv4 Home Address Option defined in section 3.1.1 of [ID-DSMIP6].
      This option additional considerations
   MUST be present in the Proxy applied.

   Mobile Node Attachment and Initial Binding Update message
      sent by Registration:

   o  After detecting a new mobile node on its access link, the mobile
      access gateway to must identify the mobile node and acquire its MN-
      Identifier.  If it determines that the local mobility anchor,
      when requesting IPv4 home address support.

   o mobility
      service needs to be offered to the mobile node, it MUST send a
      Proxy Binding Update message to the local mobility anchor.  The
      message MUST include the IPv4 Home Address Acknowledgment Option option, defined in
      section 3.2.1 3.1.1 of [ID-DSMIP6].  This  The mobile access gateway MAY also
      include the IPv6 Home Network Prefix option MUST be present in the Proxy Binding
      Acknowledgment, if the local mobility anchor accepts same message
      for requesting IPv6 home address support in addition to IPv4 home
      address support.

3.4.  Mobile Access Gateway Operation support for the mobile node.

   o  All  If the considerations as explained in Section 6.11 of mobile access gateway learns the mobile node's IPv4 home
      network prefix or the IPv4 home address either from its policy
      store or from the DHCP messages exchanged between the base
      Proxy Mobile IPv6 specification apply here.

   o  When a mobile node attached to an access link
      and attempts to
      obtain an the DHCP server, the mobile access gateway can specify the
      same in the IPv4 Home Address option for requesting the local
      mobility anchor to allocate that address configuration, using DHCP or other
      procedures, it will get to allocate an IPv4 address as a IPv4 home address
      from its the specified home network prefix prefix.  If the specified value is
      0.0.0.0, then the local mobility anchor will consider this as discussed in Section 3.1. a
      request for dynamic address allocation.

   o  The mobile access gateway on the access link where mobile node is
      attached, will register this address with the local mobility
      anchor using the IPv4 Home Address option, defined in Section
      3.1.1 of [ID-DSMIP6].  The IPv4 Home Address option is sent with a
      proxy binding update as shown in Figure 3. 4.  The format of the
      proxy binding update MUST be protected by IPsec ESP.  How to build is slightly different from the IPv4 home one of [ID-
      DSMIP6].  In [ID-DSMIP6], the source address option is varied as follows:

      *  If of IPv6 header must
      be a mobile access gateway needs to request dynamic IPv4 home address allocation to of the local mobility anchor, it MUST set
         0.0.0.0 in mobile terminal.  However, since Proxy
      Mobile IPv6 supports only IPv4 capable node, IPv6 home address is
      not always available on the terminal.  In addition to this, the IPv4 Home Address field
      originator of this proxy binding update is not the IPv4 mobile
      terminal, but the mobile access gateway.  The mobile access
      gateway cannot send the proxy binding update with the mobile
      node's home address option as described in [ID-DSMIP] because of security reasons (IPsec and send ingress
      filtering).  Therefore, in this option
         by specification, the mobile access
      gateway's care-of address (Proxy-CoA) is used in the IPv6 source
      address field.

   o  The proxy binding update.

      * update MUST be protected by IPsec ESP.

   Receiving Binding Registration Reply:

   o  If the received Proxy Binding Acknowledgement message has neither
      an IPv4 Address Acknowledgement option or a Home Network Prefix
      option present, the mobile access gateway knows MUST ignore the IPv4 home prefix (or home
         address) Proxy
      Binding Acknowledgement and MUST NOT enable routing for the mobile node from static mobile
      node's policy
         profile or DHCP server, it MUST set the known IPv4 Home Address or IPv6 home prefix
         to the address traffic.  However,
      if there is an IPv4 Home Address field and Acknowledgment option present in
      the Pref field of reply, the IPv4
         home address option.  This option is carried by a proxy binding
         update described MUST be processed as per the rules specified
      in Proxy Dual Stack Mobile IPv6 specification [ID-PMIP6].

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

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

         Figure 3: [ID-DSMIP6].

   o  If the received Proxy Binding Update for Acknowledgement message has the
      Status field value in the IPv4 Home Address Support

   o  When Acknowledgement Option set
      to a mobile node gets IPv4 home address from Local Mobility
      Anchor through DHCP interaction with MAG value that indicates that supports DHCP server
      functionality, the DHCP client in request was rejected by the mobile node recognizes MAG's
      IP address as DHCP server's IP address.  Thus, the DHCP client
      unicasts DHCP renew to the MAG, when the DHCP client goes into the
      DHCP RENEWING state [RFC2131].  However, when
      local mobility anchor, the mobile node
      handovers to a new MAG, access gateway MUST NOT enable
      IPv4 support for the mobile node does not know node.  However, if there is an IPv6
      Home Network Prefix option in the link
      change Proxy Binding Acknowledgement
      message and the DHCP client would unicast DHCP request to the
      previous MAG whose IP address was acquired from DHCP offer.  So,
      DHCP client Status field in the mobile node needs to reconfigure its local
      configuration parameters.  Therefore, MAG SHOULD discard any DHCP
      request message that does not belong is set to the MAG itself, so that a value 0
      (Proxy Binding Update accepted), the mobile node should go into the DHCP REBINDING state and
      broadcast DHCP request without server identifier.

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

   o  After receiving a  If the received Proxy Binding Acknowledgment Acknowledgement message with the
      IPv4 Address Acknowledgment Option and if the status code in has the
      Binding Acknowledgment and
      Status field in the IPv4 Address
      Acknowledgment values are value set to Success, 0 (Proxy Binding Update accepted), the
      mobile access gateway MUST update a Binding Update List entry and
      must setup a tunnel to the local mobility anchor and must also add
      a default route over the tunnel for all the mobile node's IPv4
      traffic.  The encapsulation modes mode for the bi-directional tunnel may be as specified in set
      to IPv4-In-IPv6 mode.  The considerations from Section 5.3 of Proxy Mobile IPv6
      specification [ID-PMIP6] and as in this specification. 6.10 [ID-
      PMIP6] apply.

   Extending Binding Lifetime:

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

3.5.  Local Mobility Anchor Operation

   o  Upon receiving send a Proxy Binding
      Update message to the local mobility anchor with a non zero
      lifetime value.  The message MUST contain the IPv4 Home Address Option, defined in Section 3.1.1 of DSMIP6 specification
      [ID-DSMIP6],
      option with the local mobility anchor, value set to the currently registered IPv4 home
      address value.  Additionally, if it determines that there is a registered IPv6 home
      network prefix for the mobile node is configured for IPv4 home address mobility service, the local mobility anchor connected interface on
      that access link, both the options, Home Network Prefix option and
      the IPv4 Home Address option MUST send be present and with the values
      set to the respective registered values.

   Mobile Node Detachment and Binding De-Registration:

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

   Constructing the Proxy Binding Update Message:

   o  The mobile access gateway when sending the Proxy Binding Update
      request to the local mobility anchor for requesting IPv4 home
      address acknowledgment are described in [ID-DSMIP6]. mobility support MUST construct the message as specified
      below.

               IPv6 header (src=PCoA, (src=Proxy-CoA, dst=LMAA)
                    Mobility header
                        -BA
                        -BU /*P flag is & A flags are set*/
                       Mobility Options
                          -HNP* /*IPv6 home address*/
                          -TSO*
                          -IPv4-ACK
                          -IPv4-DRA
         *HNP: Home Network Prefix Option
         *TSO: Time Stamp
                          - Timestamp Option (optional)
                          - Mobile Node Identifier option
                          - Access Technology Type option (Mandatory)
                          - Mobile Node Interface Identifier option
                            (Optional)

                          - IPv4 Home Address option (Mandatory)
         Figure 4: Proxy Binding Acknowledgement Update for IPv4 Home Address Support

   o  After accepting the registration for the mobile node's IPv4 home
      address,  The source address field of the local mobility anchor will add an IPv4 host route
      over IPv6 header MUST be the tunnel to IPv6
      address of the mobile access gateway.  Any

   o  The IPv4 packets
      that the local mobility anchor receives from a correspondent node
      will Home Address option [ID-DSMIP6] MUST be tunneled present.  The
      address value MAY be set 0.0.0.0 or to a specific value.

   o  All the mobile access gateway over the bi-
      directional tunnel, other fields and then routed accordingly after removing the
      tunnel header.  The encapsulation modes for the bi-directional
      tunnel may options MUST be constructed, as
      specified in Section 5.3 of Proxy Mobile IPv6
      specification [ID-PMIP6] [ID-PMIP6].

   DHCP Messages from the mobile node:

   o  When a mobile node attached to an access link and attempts to
      obtain an IPv4 address configuration, using DHCP or other
      procedures, it will get an IPv4 address as in this specification.

4. an IPv4 Transport Support

   As per the Proxy Mobile IPv6 specification [ID-PMIP6], the transport home address
      from its home network between the local mobility anchor and the prefix as discussed in Section 3.1.  The
      mobile access gateway is an IPv6 network.  This specification defines extensions
   for supporting on the scenario access link where mobile node is
      attached, will register this address with the local mobility
      anchor and using the
   mobile access gateway may be separated by an IPv4 transport network
   and further these entities may be configured with Home Address option, defined in Section
      3.1.1 of [ID-DSMIP6].  The IPv4 private
   addresses and Home Address option is sent with NAT translation devices a
      proxy binding update as shown in the path. Figure 4

   o  When the network between the local mobility anchor and the a mobile
   access gateway is node obtains an IPv4 network, home address from DHCP server,
      the mobile access gateway can
   potentially register an IPv4 address with the local mobility anchor,
   as SHOULD record the care-of assigned IPv4 home
      address in the policy profile.  A new mobile node's binding cache entry and
   thus creating an IPv4 tunnel for carrying all the mobile node's
   traffic.

   The DSMIPv6 specification [ID-DSMIP6] defines access gateway can
      send a solution for allowing proxy binding update when a mobile node roams to roam over an IPv4 network and the same solution can
   be extended new
      mobile access gateway.

   o  When a mobile node first attaches to a Proxy Mobile IPv6.  As explained in Section 4.1, of
   the DSMIPv6 specification, IPv6 domain, a
      mobile access gateway can encapsulate triggers a
   Proxy Binding Update IPv6 message in an IPv4-UDP packet and route it
   to proxy binding update by following
      conditions.  It is rarely happened that the local mobility anchor.  The processing logic DHCP procedure and
      proxy binding procedure run at the on path
   NAT detection logic same time except for the
      initial attachment.

      *  When a mobile access gateway is just as described in Section 4.3.  The
   signaling messages will always be IPv6 messages encapsulated in an
   IPv4 packet and carried as an IPv4 packet.  The data traffic to and a DHCP server, it MUST send a
         proxy binding update right after receiving a DHCP discovery
         message from the a mobile node will also be encapsulated and carried as IPv4
   packets.  This specification does not cover node.  By sending the dynamic discovery of proxy binding
         update, it will learn the assigned IPv4 home address of from the
         local mobility anchor (IPv4-LMAA) and thus it anchor.

      *  When a DHCP relay is assumed that the co-located with a mobile access gateway can learn this address from gateway,
         the mobile node's policy profile or access gateway MUST send a proxy binding update as
         soon as it can obtain this information
   through other techniques that are beyond the scope of this document.

4.1.  Mobility Options

   For supporting IPv4 transport support, the following options are
   required receives a DHCP Acknowledgement message from the DSMIP6 specification [ID-DSMIP6].

   o  NAT detection Option, defined in section 3.2.2 of
         DHCP server.  During the DSMIP
      specification [ID-DSMIP6].  This option proxy binding registration, it MUST be present in
         NOT relay the
      Proxy Binding Acknowledgment when DHCP Acknowledgement message to the local mobility anchor
      detects NAT in DHCP client.
         After the path between proxy binding is successfully registered, the DHCP
         relay (i.e. mobile access gateway and itself.

4.2.  Extensions to Conceptual Data Structure

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

4.3.  NAT Detection

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

   When gateway) MUST forward the transport network between DHCP
         Acknowledgement to the local mobility anchor DHCP client (i.e. mobile node).  Before
         a DHCP Acknowledgement message, a DHCP client and the
   mobile access gateway is an DHCP
         server do not complete the negotiation of IPv4 network, address
         assignment so that the mobile access gateway
   must MAY send Proxy Binding Update message encapsulated in an IPv4-UDP
   packet.  On receiving this Proxy Binding Update packet encapsulated
   in an IPv4-UDP packet, a
         different IPv4 address to the local mobility anchor if it detects by a NAT
   on the path, will send the Proxy Binding Acknowledgment message with proxy
         binding update.

   o  After the NAT Detection Option.  The presence of this option initial procedure described in above, DHCP runs
      independently to the Proxy
   Binding Acknowledgment proxy binding registration for renewing the
      assigned IPv4 home address.  It is an indication not necessary to the run DHCP
      whenever a mobile access gateway
   about the presence of NAT in node changes its attached mobile access gateway.
      A DHCP client renew the path.  On detecting address according to the NAT in address lifetime,
      etc.  However, whenever a mobile node renews the
   path, both IPv4 home address
      by DHCP (DHCP RENEWING STATE [RFC-2131]), the mobile access
      gateway SHOULD send a proxy binding update to the local mobility
      anchor and regardless of the mobile node's assigned address changes.

   o  When a mobile node gets IPv4 home address from Local Mobility
      Anchor through DHCP interaction with mobile access gateway
   will set that
      supports DHCP server functionality, the encapsulation mode of DHCP client in the tunnel mobile
      node recognizes mobile access gateway's IP address as DHCP
      server's IP address.  Thus, the DHCP client unicasts DHCP renew to IPv4-UDP.  The
   specific details around
      the NAT detection and mobile access gateway, when the related logic is
   described in in Dual Stack for Mobile IPv6 specification [ID-DSMIP6].

4.4.  Mobile Access Gateway Operation

   o  All DHCP client goes into the considerations as explained in Section 6.11 of DHCP
      RENEWING state [RFC-2131].  However, when the base
      Proxy Mobile IPv6 specification apply here.

   o  If IPv4 transport support is enabled in order mobile node
      handovers to place a new mobile access gateway at IPv4 only network, gateway, the mobile access gateway
      MUST have an IPv4 address at node does not
      know the visiting network.  In addition link change and the DHCP client would unicast DHCP
      request to
      that, the previous mobile access gateway MUST also obtain IPv6 whose IP address
      configured for the Proxy Mobile IPv6 operation.  Even if was
      acquired from DHCP offer.  So, DHCP client in the mobile node
      needs to reconfigure its local configuration parameters.
      Therefore, mobile access gateway SHOULD discard any DHCP request
      message that does not have connectivity belong to the IPv6
      network, it MUST configure with an IPv6 address for sending the
      proxy binding registration to the local mobility anchor.

   o  As explained in Section 4.1, of the DSMIPv6 specification, the mobile access gateway can encapsulate a Proxy Binding Update
      message and carry it in IPv4 and UDP packet.  The processing logic
      for handling the NAT detection at itself,
      so that the mobile node is applicable should go into the DHCP REBINDING state
      and broadcast DHCP request without server identifier.

3.3.  Local Mobility Anchor Considerations

3.3.1.  Extensions to Binding Cache Entry

   For supporting this feature, the mobile access gateway conceptual Binding Cache entry data
   structure needs to be extended with the following additional
   parameter, as described specified in Section 4.3.  An example
      of proxy binding update sent by mobile access gateway [ID-DSMIP6] specification and is shown in
      Figure 5.  Note that the source presented
   here for convenience.

   o  The IPv4 home address of the inner IPv6 header
      MUST set to the IPv6 registered mobile node.  The IPv4
      home address assigned to value may have been statically configured in the
      mobile access gateway
      and the destination address MUST be node's policy profile, it MAY have been assigned by a DHCP
      server, or it MAY have been dynamically allocated by the local
      mobility anchor's
      IPv6 address (LMAA).  The source anchor.

3.3.2.  Signaling Considerations

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

   Processing Binding Registrations:

   o  If there is an IPv4 Home Address option present in the IPv4-proxy-CoA and request,
      but if there is no Home Network Prefix option present in the destination MUST be
      request, the local mobility anchor's IPv4 address (IPv4-LMAA).  For anchor MUST NOT reject the NAT handling,
      UDP header request as
      specified in [ID-PMIP6].  At least one of these two options MUST
      be always used for present.  However, if both the proxy binding update.  The
      UDP port number is defined in [ID-DSMIP6].  The proxy binding
      update MUST be protected by IPsec ESP.  The security association
      for IPv4 addresses of options are not present, the mobile access gateway and
      local mobility anchor are pre-established.

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

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

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

   o  After receiving request and send a Proxy
      Binding Acknowledgment Acknowledgement message
      encapsulated in an IPv4 packet, the with Status field set to
      MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile access gateway node's home
      network prefix option).

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

   o  If there is no existing Binding Cache entry that matches the Status field indicates Success,
      request, the mobile access gateway local mobility anchor MUST setup a tunnel to consider this request as
      an initial binding registration request.  If the entry exists, the
      local mobility anchor and add MUST consider this request as a default
      route over binding re-
      registration request.

   o  The proxy care-of address MUST be retrieved from the tunnel for all source
      address field of the mobile node's IPv6 traffic. proxy binding update message.

   o  If the NAT is available and the NAT detection IPv4 Home Address option is presented present in the Proxy Binding Acknowledgment,
      Update request has the mobile access gateway value of 0.0.0.0, the local mobility anchor
      MUST
      use UDP tunnel to traverse allocate an IPv4 home address for the NAT mobile node and MUST send a proxy binding
      update every refresh time specified in
      Proxy Binding Acknowledgement message and including the NAT detection option.
      The detailed operation can be found IPv4
      Address Acknowledgement option, defined in DSMIP6 specification Section 3.2.1 of [ID-
      DSMIP6].

   o  If the Status field in
      DSMIP6], containing the proxy binding acknowledgment indicates allocated address value.  The specific
      details on how the rejection of local mobility anchor allocates the binding registration, home
      address is outside the mobile access
      gateway scope of this document.  The local mobility
      anchor MUST not enable IPv4 transport for ensure the allocated prefix is not in use by any other
      mobile node's
      traffic. node.

   o  On receiving any packets from  If the mobile node's IPv6 home address
      and/or local mobility anchor is unable to allocate an IPv4 home address,
      address for the mobile access gateway tunnels node, it MUST reject the
      packets request and send a
      Proxy Binding Acknowledgement message with Status field set to 130
      (Insufficient resources).

   o  Upon accepting the request, the local mobility anchor as shown in Figure 6
               IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
                   UDP header /*Only if NAT is detected*/
                       union { /*following either v6 or v4 header */
                           IPv4 header (src=MN's IPv4-HoA, dst=IPv4 CN)
                           IPv6 header (src=MN's IPv6-HoA, dst=IPv6 CN)
                       }
                               Upper layer protocols /*TCP,UDP,SCTP*/

                  Figure 6: Tunneled Packets from MAG to LMA

4.5.  Local Mobility Anchor Operation

   When MUST create
      a Binding Cache entry for the mobile node is attached node.  It must set the fields
      in the Binding Cache entry to the accepted values for that
      binding.  It MUST also establish a bi-directional tunnel to the
      mobile access gateway that is
   reachable only through an IPv4 transport network, the gateway, as described in [RFC-2473].  Considerations
      from Section 5.6 [ID-PMIP6] MUST be applied.  The local mobility
      anchor must establish MUST add an IPv4 tunnel host route for routing the mobile node's that allocated IPv4 and IPv6 home
      address traffic.  The DSMIPv6 specification
   provides over the semantics on how the IPv4 tunnel needs to be negotiated
   and the detection logic of the NAT devices.  This specification
   leverages the NAT Detection Option, defined in the DSMIP6
   specification for the use in Binding Acknowledgment message and
   extends it to Proxy Binding Acknowledgment messages.  The operational
   steps are defined below. mobile access gateway.

   Multihoming Considerations:

   o  Upon receiving a Proxy Binding Update message encapsulated  The multihoming considerations specified in an
      IPv4 packet, Section 5.4 [ID-PMIP6]
      allows the local mobility anchor MUST send to perform the Proxy Binding
      Acknowledgment to Cache
      entry existence test for identifying the mobile access gateway's IPv4-Proxy-CoA mobility session, by
      using the mobile node identifier, interface identifier and the
      Home Network Prefix values.  When using an IPv4 encapsulation.  If home address
      value, instead of the NAT is detected, IPv6 home network prefix for matching the NAT
      detection
      Binding Cache entry, all those considerations equally apply for
      the IPv4 home address as well.

   o  If there is an Home Network Prefix option MUST be used present in the Proxy
      Binding Acknowledgment.
      How to detect NAT is described in Section 4.1 of [ID-DSMIP6] Update request and
      Section 4.3.

   o  An example of proxy binding acknowledgment sent by with a NON_ZERO value, the local
      mobility anchor is shown below.  The same illustration MUST use this parameter in combination with the
      mobile node identifier and interface identifier for Mobile IPv6 can
      be found matching the
      Binding Cache entry, just as specified in Section 4.1 of [ID-DSMIP6].  The proxy binding
      acknowledgment 5.4 [ID-PMIP6].
      For all other cases, the local mobility anchor MUST be protected by IPsec ESP.  The security
      association for use the IPv4 addresses of
      home address parameter in combination with the mobile access gateway node
      identifier and interface identifier for matching the Binding Cache
      entry, as specified in Section 5.4 [ID-PMIP6].

   Constructing the Proxy Binding Acknowledgement Message:

   o  The local mobility anchor are pre-established.

              IPv4 header (src=IPv4-LMAA, dst=IPv4-proxy-CoA)
                  UDP header /*Only if NAT is detected*/
                   IPv6 header (src=LMAA, dst=v6MAG)
                      Mobility header
                          -BA /*P when sending the Proxy Binding
      Acknowledgement message to the mobile access gateway MUST
      construct the message as specified below.

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

      *HNP: Home Network Prefix
                       - Timestamp option (optional)
                       - Mobile Node Identifier Option
      *TSO: Time Stamp
                       - Access Technology Type option (Mandatory)
                       - Mobile Node Interface Identifier option
                            (Optional)

                       - IPv4 Address Acknowledgement Option
      *v6MAG:  IPv6 address assigned to the mobile access gateway. (Mandatory)

        Figure 7: 5: Proxy Binding Acknowledgment in Acknowledgement for IPv4 network Home Address
                                   Support

   o  After accepting the registration from the mobile access gateway
      locating at the IPv4 only network,  The destination address field of the local mobility anchor IPv6 header MUST
      setup a tunnel be set to
      the mobile access gateway.

   o  The tunnel is
      established between the v4-LMAA and the IPv4-Proxy-CoA of IPv4 Address Acknowledgement option MUST be present in the
      mobile access gateway.
      Proxy Binding Acknowledgement message.  If both the NAT is available IPv4 Home
      Address option and the NAT
      detection IPv6 Home Network Prefix option is included were not
      present in the Proxy Binding Acknowledgment, Update request and if the local mobility anchor MUST use UDP encapsulation for Status
      field value in the
      tunnel.  The local mobility anchor also setup a host routes for message is set to
      MISSING_HOME_NETWORK_PREFIX_OPTION, the value MUST be set to
      ALL_ZERO.  For all other Status values, the IPv4 home address and
      value MUST be set to the IPv6 home allocated address of the value for that mobile node
      over
      node.  Considerations from [ID-DSMIP6] MUST be applied on
      determining Status field value in the tunnel to option.

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

3.3.3.  Routing Considerations

   Forwarding Considerations for the mobile access gateway.  Any traffic that node's IPv4 home address
   traffic.

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

   o  When the local mobility anchor receives from is serving a correspondent node will
      be tunneled mobile node, it MUST
      be able to receive packets that are sent to the mobile access gateway over node's IPv4
      network.  In order for it to receive those packets, it MUST
      advertise a connected route in to the bi-directional
      tunnel and then routed accordingly after removing Routing Infrastructure for
      the tunnel
      headers.  The encapsulation modes mobile node's IPv4 home network prefix or for an aggregated
      prefix with a larger scope.  This essentially enables IPv4 routers
      in that network to detect the bi-directional tunnel
      may be local mobility anchor as specified in Section 5.3 of Proxy the last-
      hop router for that IPv4 prefix.

   Forwarding Packets to the Mobile IPv6
      specification [ID-PMIP6] and as in this specification. Node:

   o  When sending any packets meant to  On receiving a packet from a correspondent node with the
      destination address matching a mobile node's IPv4 home
      address or IPv6 home address,
      the local mobility anchor tunnels MUST forward the packet to through the bi-
      directional tunnel setup for that mobile access gateway as shown in Figure 8

               IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA)
                   UDP header /*Only if NAT node.  The format of the
      tunneled packet is detected*/
                       union { /*following either v6 or v4 shown below.

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

                  Figure 8: 6: Tunneled Packets from LMA to MAG

4.6.  Tunnel Management

   As

   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.

4.  IPv4 Transport Support

   The Proxy Mobile IPv6 specification, specification [ID-PMIP6] assumes the bi-
   directional tunnel network
   between the local mobility anchor and the mobile access gateway, is a shared tunnel gateway to be
   an IPv6 network and all requires the considerations from
   Section 6.6 of Proxy Mobile IPv6 [ID-PMIP6] apply for IPv4 transport
   as well.

5.  IANA Considerations

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

6.  Security Considerations

   This specification describes the use of IPv4 transport network signaling messages exchanged between
   the local mobility anchor and the mobile access gateway.  All gateway to be over an
   IPv6 transport.  The extensions defined in this section allow the
   exchange of signaling messages exchanged between the mobile access gateway over an IPv4 transport and when the
   local mobility anchor over and the mobile access gateway are separated by
   an IPv4 transport MUST be
   protected using IPsec, just as the messages must be protected when
   using IPv6 transport network and as specified potentially even configured with IPv4 private
   addresses and with NAT translation devices in the Section 4.0, of the
   Proxy Mobile IPv6 specification [ID-PMIP6].

   When supporting path.

             IPv4-Proxy-CoA                      IPv4-LMAA
                    |         + - - - - - - +        |
    +--+          +---+      /               \     +---+          +--+
    |MN|----------|MAG|=====   IPv4 address assignment from a DHCP server, all the  Network  =====|LMA|----------|CN|
    +--+          +---+      \               /     +---+          +--+
                              + - - - - - - +

                     Figure 7: IPv4 home addresses managed in Transport Network

   When the network between the DHCP server must be reachable via
   local mobility anchor so that local mobility anchor intercepts
   packets meant for an IPv4 home address and tunnels them to the mobile
   node via corresponding mobile
   access gateway.  Moreover, all the DHCP
   messages between a DHCP relay and gateway is an IPv4 network, the DHCP server SHOULD be securely
   exchanged.

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

   When supporting dynamic IPv4 care-of address assignment by DHCP in the mobile node's Binding Cache entry and also from
   local mobility anchor, it should be ensured both
   thus creating an IPv4 tunnel for carrying all the entities are
   configured with different address pools, so as mobile node's
   traffic.

   The DSMIPv6 specification [ID-DSMIP6] defines a solution for allowing
   a mobile node to avoid both entities
   do not allocate roam over an IPv4 network and the same address mechanism is
   extended to different Proxy Mobile IPv6.  As explained in Section 4.1, of the
   [ID-DSMIP6], a mobile nodes.

7.  Contributors

   This document reflects discussions access gateway MUST send a Proxy Binding Update
   IPv6 message by IPv4 UDP-based encapsulation and contributions from several
   people (in alphabetical order):

   Kuntal Chowdhury

      kchowdhury@starentnetworks.com

   Vijay Devarapalli

      vijay.devarapalli@azairenet.com

   Sangjin Jeong

      sjjeong@etri.re.kr

   Basavaraj Patil

      basavaraj.patil@nsn.com

   Myungki Shin

      myungki.shin@gmail.com

8.  Acknowledgments route it to the
   local mobility anchor.  The IPv4 support for Proxy Mobile processing logic and the on path NAT
   detection logic are just as described in Section 4.1.  The signaling
   messages will always be IPv6 was initially covered messages encapsulated in an IPv4 packet
   and carried as an IPv4 packet.  The data traffic to and from the
   internet-draft [draft-sgundave-mip6-proxymip6-02.txt].
   mobile node will also be encapsulated and carried as IPv4 packets.
   This document
   leverages lot specification does not cover the dynamic discovery of text from that document.  We would like to thank all the authors IPv4
   address of the document local mobility anchor (IPv4-LMAA) and acknowledge thus it is
   assumed that initial work.

9.  References

9.1.  Normative References

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

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

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

   [RFC-2131] Droms, R., the mobile access gateway can learn this address from
   the mobile node's policy profile or it can obtain this information
   through other techniques that are beyond the scope of this document.

4.1.  NAT Detection

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

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

4.2.  Mobile Access Gateway Considerations

4.2.1.  Extensions to Binding Update List Entry

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

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

4.2.2.  Signaling Considerations

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

   Network Configurations for IPv4 Transport Signaling Support:

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

   Processing Binding Registrations:

   o  As explained in the DSMIPv6 specification, the mobile access
      gateway can encapsulate a Proxy Binding Update message and carry
      it in IPv4 and UDP packet.  The processing logic for handling the
      NAT detection at the mobile node is applicable to the mobile
      access gateway as described in Section 4.1.

   o  An example of proxy binding update sent by mobile access gateway
      is shown in Figure 8.  The source address of the inner IPv6 header
      MUST set to the IPv6 address assigned to the mobile access gateway
      and the destination address MUST be the local mobility anchor's
      IPv6 address (LMAA).  This is slightly different from [ID-DSMIP6]
      .  The reason is already mentioned in Section 3.2.2.

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

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

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

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

   o  The proxy binding update MUST be protected by IPsec ESP.  The
      security association for IPv4 addresses of the mobile access
      gateway and local mobility anchor are pre-established.

   Constructing the Proxy Binding Update Message:

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

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

                            - The IPv4 Care-of Address option(Mandatory)

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

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

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

   Receiving Binding Registration Reply:

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

   o  If the Status field indicates Success, the mobile access gateway
      MUST setup a tunnel to the local mobility anchor and add a default
      route over the tunnel for all the mobile node's traffic.

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

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

   Forwarding Packets to Local Mobility Anchor

   o  On receiving any packets from the mobile node's IPv6 home address
      and/or IPv4 home address, the mobile access gateway tunnels the
      packets to local mobility anchor as shown in Figure 9.  If the
      mobile access gateway and the local mobility anchor agreed to use
      the TLV header for the UDP tunnel during the binding registration,
      the TLV header MUST be presented after the UDP header as shown in
      Figure 10.

               IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
                   [UDP header] /*Only if NAT is detected*/
                       union { /*following either v6 or v4 header */
                           IPv4 header (src=MN's IPv4-HoA, dst=IPv4 CN)
                           IPv6 header (src=MN's IPv6-HoA, dst=IPv6 CN)
                       }
                               Upper layer protocols /*TCP,UDP,SCTP*/

                  Figure 9: Tunneled Packets from MAG to LMA

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

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

4.3.  Local Mobility Anchor Considerations

4.3.1.  Extensions to Binding Cache Entry

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

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

4.3.2.  Signaling Considerations

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

   Processing Binding Registrations:

   o  After accepting the registration from the mobile access gateway
      locating at the IPv4 only network, the local mobility anchor MUST
      setup a tunnel to the mobile access gateway.  The tunnel is
      established between the v4-LMAA and the IPv4-Proxy-CoA of the
      mobile access gateway.

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

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

   o  The local mobility anchor also setup a host routes for the IPv4
      home address and the IPv6 home address of the mobile node over the
      tunnel to the mobile access gateway.  Any traffic that the local
      mobility anchor receives from a correspondent node will be
      tunneled to the mobile access gateway over the bi-directional
      tunnel and then routed accordingly after removing the tunnel
      headers.  The encapsulation modes for the bi-directional tunnel
      are as specified in Section 5.3 of Proxy Mobile IPv6 specification
      [ID-PMIP6] and as in this specification.

   o  Upon receiving a Proxy Binding Update message encapsulated in an
      IPv4 packet, the local mobility anchor MUST send the Proxy Binding
      Acknowledgment to the mobile access gateway's IPv4-Proxy-CoA by
      using IPv4 encapsulation.

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

   Constructing the Proxy Binding Acknowledgement Message:

   o  The proxy binding acknowledgment MUST be protected by IPsec ESP.
      The security association for IPv4 addresses of the mobile access
      gateway and local mobility anchor are pre-established.

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

   o  An example of proxy binding acknowledgment sent by local mobility
      anchor is shown below.  The same illustration for Mobile IPv6 can
      be found in Section 4.1 of [ID-DSMIP6].

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

                             - NAT Detection Option (Optional)

           Figure 11: Proxy Binding Acknowledgment in IPv4 network
   Forwarding Packets to Mobile Access Gateway

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

               IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA)
                   [UDP header] /*Only if NAT is detected*/
                       union { /*following either v6 or v4 header */
                           IPv4 header (src=IPv4-CN, dst=IPv4-HoA)
                           IPv6 header (src=IPv6-CN, dst=IPv6-HoA)
                       }
                               Upper layer protocols /*TCP,UDP,SCTP*/

                 Figure 12: Tunneled Packets from LMA to MAG

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

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

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

4.4.  Tunnel Management

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

5.  IANA Considerations

   This document does not require IANA Action.

6.  Security Considerations

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

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

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

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

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

7.  Contributors

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

   Kuntal Chowdhury

      kchowdhury@starentnetworks.com

   Vijay Devarapalli

      vijay.devarapalli@azairenet.com

   Sangjin Jeong

      sjjeong@etri.re.kr

   Basavaraj Patil

      basavaraj.patil@nsn.com

   Myungki Shin

      myungki.shin@gmail.com

8.  Acknowledgments

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

9.  References

9.1.  Normative References

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

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

   [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling 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] Gundavelli, S., et.al, "Proxy Mobile IPv6",
   draft-ietf-netlmm-proxymip6-07.txt, November 2007.

9.2.  Informative References

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

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

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

Appendix A.  DHCP usages for IPv4 home address assignment

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

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

   o  DHCP relay is located in each mobile access gateway and DHCP
      server is solely located in the Proxy Mobile IPv6 Specification", RFC 2473, December 1998.

   [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support domain

   o  DHCP relay is located in
   IPv6", RFC 3775, June 2004.

   [RFC-3776] Arkko, J., Devarapalli, V., both each mobile access gateway and a
      local mobility anchor.  DHCP server is solely located in the Proxy
      Mobile IPv6 domain

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

     MN   MAG(DHCP-R) DHCP-S    LMA
      |------>|------->|       |  1. DHCP discovery
      |<------|<-------|       |  2. DHCP offer (IPv4 HoA) and Relay
      |------>|------->|       |  3. DHCP request (IPv4 HoA) and Relay
      |       |<-------|       |  4. DHCP acknowledgement and F. Dupont, "Using IPsec Relay
      |       |--------------->|  5. Proxy Binding Update
      |       |<---------------|  6. Proxy Binding Acknowledgement
      |       |================|  7. Tunnel/Route Setup
      |<------|        |       |  8. DHCP acknowledgement to
   Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents",
   RFC 3776, June 2004.

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

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

   [RFC-4832] Vogt, C., Kempf, J., "Security Threats client
      |       |        |       |

              Figure 14: The use of an Independent DHCP relay

   Figure 15 is very similar to Network-Based
   Localized Mobility Management", September 2006.

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

   [ID-MIP6-IKEV2] Devarapalli, V. the local
   mobility anchor being a DHCP relay.  In this case, both a mobile
   access gateway and Dupont, F., "Mobile IPv6
   Operation with IKEv2 local mobility anchor relay the DHCP messages from
   and to the revised IPsec Architecture",
   draft-ietf-mip6-ikev2-ipsec-08.txt, December 2006.

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

9.2.  Informative References

   [RFC-2460] Deering, S. mobile nodes.

     MN  MAG(DHCP-R) LMA(DHCP-R) DHCP-S
      |------>|------->|------>|  1. DHCP discovery and R. Hinden, "Internet Protocol, Version 6
   (IPv6) Specification", RFC 2460, December 1998.

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

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

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

   [RFC-4301] Kent, S. Relay
      |------>|------->|------>|  3. DHCP request (IPv4 HoA) and Atkinson, R., "Security Architecture for the
   Internet Protocol", RFC 4301, December 2005.

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

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

   [ID-DSMIP6-PS] Tsirtsis, G., et.al, "Problem Statement: Dual Stack
   Mobility", draft-ietf-mip6-dsmip-problem-03.txt, January 2007. Relay
      |       |<-------|<------|  4. DHCP acknowledgement and Relay
      |       |------->|       |  5. Proxy Binding Update
      |       |<-------|       |  6. Proxy Binding Acknowledgement
      |       |========|       |  7. Tunnel/Route Setup
      |<------|        |       |  8. DHCP acknowledgement to client
      |       |        |       |
      * Tunnel setup(no.5) and DHCP offer/request/ack(no.6-8)
        are processed in parallel.

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

Authors' Addresses

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

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

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

   Email: sgundave@cisco.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

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