MIP4
Network Working Group                                           K. Leung
Internet-Draft
Request for Comments: 5563                                    G. Dommety
Intended status:
Category: Informational                                        P. Yegani
Expires: June 1, 2009
                                                           Cisco Systems
                                                            K. Chowdhury
                                                        Starent Networks
                                                            Nov 28, 2008
                                                                May 2009

                 WiMAX Forum/3GPP2 Forum / 3GPP2 Proxy Mobile IPv4
                   draft-leung-mip4-proxy-mode-10.txt

Status of this This Memo

   By submitting this Internet-Draft, each author represents that

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any
   applicable patent or other IPR claims kind.  Distribution of which he or she this
   memo is aware
   have been or will be disclosed, unlimited.

Copyright Notice

   Copyright (c) 2009 IETF Trust and any the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of which he
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

   This document may contain material from IETF Documents or she becomes
   aware will be disclosed, IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in accordance with Section 6 some of BCP 79.

   Internet-Drafts are working documents this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate created outside the IETF Standards Process, except to use Internet-Drafts format
   it for publication as reference
   material an RFC or to cite them translate it into languages other
   than as "work in progress."

   The list English.

IESG Note

   This RFC is not a candidate for any level of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt. Internet Standard.  The list
   IETF disclaims any knowledge of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire the fitness of this RFC for any
   purpose and in particular notes that the decision to publish is not
   based on June 1, 2009. IETF review for such things as security, congestion control,
   or inappropriate interaction with deployed protocols.  The RFC Editor
   has chosen to publish this document at its discretion.  Readers of
   this document should exercise caution in evaluating its value for
   implementation and deployment.  See RFC 3932 for more information.

Abstract

   Mobile IPv4 is a standard mobility protocol that enables an IPv4
   device to move among networks while maintaining its IP address.  The
   mobile device has the Mobile IPv4 client function to signal its
   location to the routing anchor, known as the Home Agent.  However,
   there are many IPv4 devices without such capability due to various
   reasons.  This document describes Proxy Mobile IPv4 (PMIPv4), a
   scheme based on

   having the Mobile IPv4 client function in a network entity to provide
   mobility support for an unaltered and mobility-unaware IPv4 device.
   This document also describes a particular application of PMIPv4 as
   specified in the WiMAX Forum and another application that is to be
   adopted in 3GPP2.

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4 ....................................................3
   2. Conventions used Used in this document  . . . . . . . . . . . . . .  4 This Document ...............................4
   3. Benefits of Proxy Mobile IPv4  . . . . . . . . . . . . . . . .  6 ...................................6
   4. Overview of Proxy Mobile IPv4  . . . . . . . . . . . . . . . .  8 ...................................7
      4.1. Mobility Signaling for Mobile Device . . . . . . . . . . .  8 .......................7
           4.1.1. Proxy Registration during Initial Network
                  Attachment . . . . . . . . . . . . . . . . . . . . . .  9 ..........................................8
           4.1.2. Proxy Registration Renewal . . . . . . . . . . . . . . 11 .........................11
           4.1.3. Proxy Handover Support . . . . . . . . . . . . . . . . 12 .............................12
           4.1.4. Resource Cleanup . . . . . . . . . . . . . . . . . . . 14 ...................................13
      4.2. Establishment of a Bi-Directional Tunnel . . . . . . . . . . 14 ..................14
           4.2.1. Packet Forwarding  . . . . . . . . . . . . . . . . . . 15 ..................................14
           4.2.2. Broadcast and Multicast  . . . . . . . . . . . . . . . 15 ............................14
           4.2.3. Forwarding Between between Devices on same the Same PMA . . . . . . . . 15 .........15
      4.3. Security Association Between between the PMA and the HA  . . . . . 16 ...........15
      4.4. Registration Sequencing  . . . . . . . . . . . . . . . . . 16 ...................................15
      4.5. Mobile Device Interface Configuration  . . . . . . . . . . 17 .....................16
      4.6. Dynamic HA Discovery . . . . . . . . . . . . . . . . . . . 17 ......................................16
   5. Proxy Mobile IPv4 Extensions . . . . . . . . . . . . . . . . . 17 ...................................16
      5.1. PMIPv4 Per-Node Authentication Method Extension  . . . . . 17 ...........17
      5.2. Proxy Mobile IPv4 Interface ID Extension . . . . . . . . . 18 ..................18
      5.3. Proxy Mobile IPv4 Device ID Extension  . . . . . . . . . . 19 .....................18
      5.4. Proxy Mobile IPv4 Subscriber ID Extension  . . . . . . . . 20 .................19
      5.5.  PMIP PMIPv4 Access Technology Type Extension  . . . . . . . . . . 21 ...................20
   6. Appearance of Being at Home Network  . . . . . . . . . . . . . 23 ............................22
      6.1. ARP Considerations . . . . . . . . . . . . . . . . . . . . 23 ........................................22
      6.2. ICMP Considerations  . . . . . . . . . . . . . . . . . . . 23 .......................................23
      6.3. DHCP Considerations  . . . . . . . . . . . . . . . . . . . 24 .......................................23
      6.4. PPP IPCP Considerations  . . . . . . . . . . . . . . . . . 25 ...................................24
      6.5. Link-Local Multicast and Broadcast Considerations  . . . . 25 .........24
   7. Proxy Mobility Agent Operation . . . . . . . . . . . . . . . . 25 .................................24
   8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 26 ...........................................25
      8.1. Processing Proxy Registration Requests . . . . . . . . . . 27 ....................26
   9. Mobile Device Operation  . . . . . . . . . . . . . . . . . . . 27 ........................................26
      9.1. Initial Network Access . . . . . . . . . . . . . . . . . . 28 ....................................27
      9.2. Mobile Device Mobility . . . . . . . . . . . . . . . . . . 28 ....................................27
      9.3. Sending and Receiving Packet . . . . . . . . . . . . . . . 28 Packets .............................27
   10. Proxy Mobile IPv4 Use Case in WiMAX  . . . . . . . . . . . . . 29 ...........................28
      10.1. Proxy Mobile IPv4 Call Flow Examples with Split
            PMA in WiMAX  . . . . . . . . . . . . . . . . . . . . . . . . . . 32 .............................................31
   11. Proxy Mobile IPv4 Use Case in 3GPP2  . . . . . . . . . . . . . 34 ...........................33
      11.1. HO considerations Handover Considerations in 3GPP2 . . . . . . . . . . . . . . . . 36 .........................36
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 38 ...........................................37
      12.1. Mobile IPv4 Extension Types  . . . . . . . . . . . . . . . 39 ..............................38
      12.2. Mobile IPv4 Error Codes  . . . . . . . . . . . . . . . . . 39 ..................................38
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 39 .......................................38
   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 ..............................................38
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
   Intellectual Property and Copyright Statements . . . . . . . . . . 43 ....................................................39
      15.1. Normative References .....................................39
      15.2. Informative References ...................................39

1.  Introduction

   There are many IPv4 devices which that do not have or cannot be enabled
   with Mobile IPv4 [RFC3344] functionality.  Yet, mobility for them is
   essential.  Proxy Mobile IPv4 provides mobility support without
   "touching" these devices.  The scheme is based on network entities
   which
   that perform the mobility management mobility-management function for a mobile device.
   The location of the device is signaled by the network element on the
   access network (referred to as the Proxy Mobility Agent) Agent (PMA)) to
   inform the network entitiy entity on the home network (referred to as the
   Home Agent) Agent (HA)) associated with the IPv4 address used by the device.
   Mobile IPv4 messaging is used by the PMA and HA, which correspond to
   the RFC 3344 entities Mobile Node (in proxy mode) and Home Agent,
   respectively.

   These are some examples of Proxy Mobile IPv4:

   1.  A WLAN Wireless Local Area Network (WLAN) access point or cellular
       base station performs registration with the Home Agent when a
       mobile device is associated on the air-link.

   2.  An access router or Foreign Agent performs registration with the
       Home Agent when a mobile device is detected on the network.

   Mobile IPv4 is used by the network entities because the mobility
   protocol has the functions needed to set up the route and tunneling
   endpoints for the mobile device's IP address and to deliver
   configuration parameters (e.g. (e.g., DNS server addresses, default
   gateway) for enabling the mobile device's IP stack.  When Mobile IPv4
   is used in this way, the security association is between the PMA and
   the HA because these entities are the signaling endpoints.  Also,
   when the mobile device moves to a new PMA, the sequencing of messages
   sourced from multiple PMAs needs to be handled properly by the HA.

   This document describes how the network entities, PMA and HA, provide
   mobility management for the mobile device.  It is organized to cover
   the generic functionality of Proxy Mobile IPv4 and also the specifics
   pertaining to WiMAX (Section 10) and 3GPP2 (Section 11).

   Note that Proxy Mobile IPv6 [RFC5213] is an IETF standard for
   network-based mobility management that enables IP mobility for a host
   without requiring its participation in any mobility-related
   signaling.

2.  Conventions used Used in this document This Document

   The keywords "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 [RFC2119].

   The following new terminology and abbreviations are introduced in
   this document and document; all other general mobility related mobility-related terms are as
   defined in Mobile IPv4 specification [RFC3344].

   Mobile Device

      The mobile device is used to refer to an IPv4 device with its
      mobility provided by the network.  The mobile device is not
      required to participate in any mobility related mobility-related signaling for
      achieving mobility for an obtained IP address.

   Proxy Mobile IPv4 Client (PMIP (PMIPv4 Client)

      This network function is responsible for initiating and
      maintaining the proxy Proxy Mobile IPv4 registration on behalf of the
      mobile device.  Essentially, it performs the Mobile IPv4 client
      function but it is hosted in the network.  In some cases, this
      function is collocated with the Foreign Agent and Agent; in others others, it is
      not.  In both cases, proxy Proxy Mobile IPv4 registration still goes via
      the Foreign Agent at all practical effects effects, even if it is internal
      to the node.

   Home Agent (HA)

      The Home Agent that is defined in Mobile IPv4 [RFC3344] is used in
      the Proxy Mobile IPv4 scheme.  It is the topological anchor point
      for the mobile device's home network and is the entity that
      manages the mobile device's reach-ability reachability state.  The additional
      capabilities for supporting Proxy Mobile IPv4 in the Home Agent
      are defined in this document.

   Foreign Agent (FA)

      The Foreign Agent that is defined in [RFC3344] is used in the
      Proxy Mobile IPv4 scheme.  It is either collocated with or
      separate from the PMIP Client. PMIPv4 client.  It serves the purpose of tunnel
         end-point
      endpoint from Proxy Mobile IPv4 perspective.

   Access Router (AR)

      Access Router is a commonly used term that refers to the node in
      the network which that connects the hosts to the IP network.

   Proxy Mobility Agent (PMA)

      Proxy Mobility Agent is the logical entity in the network that
      encompasses both the PMIP Client PMIPv4 client and the FA functions.  The
         PMIP Client
      PMIPv4 client and the FA collocation in the Access Router
      constitute an integrated PMA.  When the PMIP Client PMIPv4 client and the FA
      functions are not collocated in the Access Router, it is referred
      to as a split PMA.  A PMIP PMIPv4 client may have association with
      multiple FAs, and vice versa.

   Proxy Registration Request (PRRQ)

      The Registration Request message is sent by the Proxy Mobility
      Agent to the Home Agent in order to set up a mobility binding
      entry for a mobile device.  The message format is identical to
      that of the Mobile IPv4 Registration Request, though the Proxy
      Mobile IPv4 extensions that are defined in this document may be
      included for enhanced features of network-based mobility
      management.

   Proxy Registration Reply (PRRP)

      The Registration Reply message is sent by the Home Agent in
      response to the Proxy Registration Request received from the Proxy
      Mobility Agent.  The message format is identical to that of the
      Mobile IPv4 Registration Reply, though the Proxy Mobile IPv4
      extensions that are defined in this document may be included for
      enhanced features of network-based mobility management.

3.  Benefits of Proxy Mobile IPv4

   Proxy Mobile IPv4 (PMIP) (PMIPv4) is designed to satisfy the requirements
   listed below.  In addition, while this specification and Proxy Mobile
   IPv4 are not standards, they employ a standard, standard: Mobile IPv4.
   Implementations of Mobile IPv4 can be re-used (i.e. (i.e., a client-based
   mobility protocol can be used "as-is" to support network-based
   mobility).  However, new PMIPv4 extensions that are added to Mobile
   IPv4 improves the flexibility of the solution.  The practical
   advantage of having a common mobility protocol for both client-based
   and network-based mobility is that a Home Agent can anchor all types
   of mobile devices, both ones that have or others and ones that lack the Mobile
   IPv4 function.

   The network-based mobility management solution defined in this
   document has the following significant reasons for its use in any
   wireless network:

   1.  Support for Unmodified Hosts

       An overwhelming majority of IPv4 hosts do not have Mobile IPv4
       capability.  Providing mobility for them is achievable using
       Proxy Mobile IPv4.  This is accomplished without "touching" the
       user's devices by running on a myriad of operating systems and
       networking stacks.

   2.  Re-use  Re-Use of Existing Home Agent

          Existing

       An existing Home Agent implementation can be used for network-
       based mobility as well.  Further enhancements are optional and
       only incremental in nature.  There are many commonalities between
       client-based and network-based mobility mobility, and sharing the same
       protocol is a significant benefit.

   3.  Reduction of Air-link Air-Link Resource Consumption

       Mobility-related signaling over the air-link is eliminated.

   4.  Support for Heterogeneous Wireless Link Technologies

       Since Proxy Mobile IPv4 is based on an access technology
          independent access, technology-
       independent, mobility protocol, it can be used for any type of
       access network.

       From the network perspective, a mobile device is identified by
       the NAI Network Access Identifier (NAI) and the forwarding is set up
       between the PMA and HA for the mobile device's current point of
       attachment on the network.  The mobile device may be attached to
       multiple networks concurrently, although the network treats each
       access interface independently.  This feature can be supported
       with the use of the PMIP PMIPv4 Access Technology Type Extension
       (Section 5.5).

   5.  Support for IPv4 and IPv6 Host Hosts

       As IPv6 increases in popularity, the host will likely be dual
       stack.  Adding IPv6 support to the host for Proxy Mobile IPv4
       involves the methods defined in [DSMIPv4]. [RFC5454].  There are additional
       enhancements needed needed, which are described in Proxy "Proxy Mobile IPv6 IPv6"
       [RFC5213].  However, support for an IPv6 host is out of scope. the scope
       of this document.

4.  Overview of Proxy Mobile IPv4

4.1.  Mobility Signaling for Mobile Device

   After the mobile device completes network access network-access authentication, the
   PMA exchanges proxy Proxy Mobile IPv4 registration messages with the HA to
   set up proper routing and tunneling of packets from/to the Mobile
   Node.  The PMIP Client PMIPv4 client is responsible for initiating the proxy Proxy
   Mobile IPv4 registration.  For integrated PMA, the PMIP Client PMIPv4 client and
   the FA interaction is all within the node.  In the case of split PMA
   implementation, the interactions between the PMIP Client PMIPv4 client and the FA
   are exposed.  The interface between the PMIP Client and the FA in the
   split PMA scenario is defined in a standards organization
   specification
   (e.g.  WiMAX R4 reference point) [NWG] and is consequently out of the scope of this
   document.

   The following call flows describe the operations of Proxy Mobile
   IPv4.  The initial network attachment, registration renewal, and
   resource cleanup procedures are covered.  Note that the protocols
   which
   that interact with Proxy Mobile IP are identified and explained in
   more details. detail.  The PPP/IPCP (IP Control Protocol) protocol involves a
   PPP client in the mobile device and NAS a Network Access Server (NAS) in
   the AR.  DHCP protocol involves a DHCP Client client in the MN and a DHCP Server server in
   either the AR or the HA.  PMIP protocol  PMIPv4 involves a PMA in the AR and an HA
   in the router on the home network.
   AAA  The Authentication,
   Authorization, and Accounting (AAA) protocol involves a AAA Client client in
   the AR and a AAA Server server in the network.  The colocation collocation of the
   functional entities in the AR/HA enables parameters to be
   shared/processed among the protocols.

   When the various network entities are not collocated, any sharing of
   parameters or other state information between them is out of the
   scope of this draft. document.

4.1.1.  Proxy Registration during Initial Network Attachment

                +----+        +-------+      +-------+      +-----+
                |    |        | AR /  |      |       |      |     |
                | MN |        | PMA   |      |  AAA  |      |  HA |
                |    |        |       |      |       |      |     |
                +----+        +-------+      +-------+      +-----+
                   |               |             |             |
                   |     1a        |     1b      |             |
   Authentication  |<------------->|<----------->|             |
                   |               |             |             |
                   |     2         |             |             |
              +->  |-------------->|             |             |
              |    |               |       3     |             |
              |    |               |-------------------------->| <-+
   Address    |    |               |             |             |   | PMIP
  Acquisition  |   |PMIP
   Acquisition|    |               |       4     |             |   |
              |    |               |<--------------------------| <-+
              |    |     5         |             |             |
              +->  |<--------------|             |             |
                   |               |             |             |
                   |     6         |             |             |
   Data Forwarding |<------------->|<=========================>|
                   |               |             |             |

                    Figure 1: Network Connection Setup

   The initial network attachment network-attachment procedure is described below.  There
   are three distinct phases.  First, authentication and authorization
   happen when the mobile device accesses the network.  Then  Then, the mobile
   device attempts to obtain an IP address.  This triggers Proxy Mobile
   IP
   IP, which assigns/authorizes the IP address and sets up forwarding
   between the PMA and HA.  The host configuration parameters may be
   passed in the PMIP PMIPv4 signaling.  Finally, the mobile device
   configures its IP stack with the IP address and the obtained host
   configuration.  Packets to and from the mobile device transit both
   the PMA and HA.

   1a.  The mobile device establishes a L2 (Layer 2) link with the base
        station (not shown) and performs access
        authentication/authorization with the AR (Access Router).
        During this phase, the mobile device may run CHAP either the
        Challenge Handshake Authentication Protocol (CHAP) [RFC1994] if
        PPP [RFC1548] [RFC1661] is used or EAP the Extensible Authentication Protocol
        (EAP) [RFC3748] over foo (foo being the specific access technology
        technology, or PANA [RFC4058]).  The AR acts as the NAS (Network
        Access Server) in this step.

   1b.  The AAA client exchanges AAA messages with the AAA
        infrastructure to perform authentication and authorization of
        the mobile device.  As part of this step, the AAA server may
        download some information about the mobile device (e.g. (e.g., the
        user's profile, handset type, assigned home agent Home Agent address, and
        other capabilities of the mobile device).

   2.   The mobile device requests for an IP address via an a PPP/IPCP
        [RFC1332] or DHCP [RFC2131].  Specifically for PPP, the PPP
        client sends an IPCP Configure-Request to the NAS.  As for DHCP,
        the DHCP client sends the DHCP Discover message to the DHCP
        relay agent/ server.

        For the DHCP case, the DHCP server or DHCP relay agent sends the
        DHCP Ack message to the DHCP client after PMIPv4 signaling had has
        completed.

   3.   Triggered by step 2, the PMA sends an a Proxy Registration Request
        (PRRQ) to the HA.  The HA's IP address is either obtained from
        the AAA server at step 1b or discovered by some other method.
        The PRRQ contains the Care-of Address (CoA) of the PMA (collocated (the
        collocated FA in this case).  The Home Address field is set to
        zero or the IP address is specified as a hint in the DHCP or
        IPCP message.  The PRRQ MUST be protected by the methods
        described in the Security Considerations (Section 13). 13) of this
        document.  The derivation and distribution of the MN-HA or FA-HA
        key is outside the scope of this document.

   4.   The home agent Home Agent sets up the mobility binding entry for the mobile
        device after assigning an IP address or authorizing the
        requested Home Address.  The home agent Home Agent may also assign a GRE
        Generic Routing Encapsulation (GRE) key in this step (if GRE
        tunneling is used between the PMA and HA).  The HA returns the
        Home Address, Address and the GRE key (if applicable) in the Proxy
        Registration Request Reply (PRRP) to the PMA.  If the requested Home
        Address is not authorized, the home agent Home Agent denies the
        registration with error code 129 (administratively prohibited).
        After the PMA processes the PRRP, the forwarding path for the
        Home Address between the PMA and HA is established.  A GRE
        tunnel may be used between the PMA and the HA [MIP4GREKEY].  The
        This event completes the Proxy Mobile IPv4 signaling for initial
        network attachment.

   5.   After the Proxy Mobile IPv4 registration exchange, the AR
        provides the IP address to the mobile device in response to step
        2.  For IPCP, the NAS replies to the PPP client with an IPCP Configure-Nak
        Configure-Nak, which includes the PMIP assigned PMIPv4-assigned Home Address
        in the IP-Address IP address configuration option and the DNS server
        address in the IPCP configuration option.

        The following procedure happens when the DHCP server is on the
        AR.  The DHCP server sends a DHCP Offer with the PMIP assigned PMIPv4-assigned
        Home Address in the yiaddr field to the DHCP client.  The DHCP
        client sends a DHCP Request to the DHCP server, which replies
        with a DHCP Ack.  The host configuration such (such as the DNS server address
        address) is included in the DHCP options in the message.  Note
        that the DHCP messages are exchanged directly between the DHCP
        client and the DHCP server.

        In the case when AR acts as a DHCP relay agent, the DHCP
        Discover is relayed to the DHCP server on the HA.  The DHCP
        server sends a DHCP Offer with the PMIP assigned PMIPv4-assigned Home Address
        in the yiaddr field to the DHCP relay agent, which forwards it
        to the DHCP client.  The DHCP Request and DHCP Ack messages are
        exchanged between the DHCP client and DHCP server via the DHCP
        relay agent.  Regardless of the sequence of PMIP PMIPv4 signaling and
        DHCP exchanges, the interaction between PMIP PMIPv4 and DHCP involves
        in the same IP address for Home Address field and yiaddr field,
        respectively.

   6.   At this step, the mobile device's IP stack is configured with an
        IP address that has a forwarding path between the AR/PMA and HA.
        Also, the host configuration such (such as DNS servers servers) is configured
        at this time.  Now that the IPCP or DHCP procedure has
        completed, the mobile device is ready to receive or send IP
        packets.  If DHCP is used, the DHCP client renews the IP address
        by sending a DHCP Request directly to the DHCP server.  The
        lease for the IP address is extended when a DHCP Ack from the
        DHCP server is received by the DHCP client.

4.1.2.  Proxy Registration Renewal

                    +----+        +-------+                  +-----+
                    |    |        | AR /  |                  |     |
                    | MN |        | PMA   |                  |  HA |
                    |    |        |       |                  |     |
                    +----+        +-------+                  +-----+
                       |               |                        |
                       |               |       1                |
                       |               |----------------------->|
     PMIP
     PMIPv4            |               |                        |
     Renewal           |               |       2                |
                       |               |<-----------------------|
                       |               |                        |
                       |               |                        |

                 Figure 2: Network Connection Maintenance

   The network connection network-connection maintenance procedure is described below.  As
   long as the mobile device remains attached to the AR, the Proxy
   Mobile IPv4 session is maintained by re-registration exchange exchanges
   between the AR and HA.

   1.  Before the PMIP PMIPv4 registration lifetime expires expires, and assuming the
       AR has not received any indication that the mobile device
       detached from the network, the PMA sends a PRRQ to the HA to
       extend the duration of the mobility binding of the mobile device.  The
       This PRRQ is similar to the initial PRRQ (i.e. (i.e., HA field set to
       the assigned HA HA, and CoA field set to the PMA), though the Home
       Address field is always set to the assigned IP address of the
       mobile device.  The mobile device's IP stack can continue to send
       and receive IP packets using the Home Address anchored at the HA.

   2.  The HA sends the PRRP in response to the PRRQ received from the
       PMA.  After the PMA processes the PRRP, the forwarding path
       between AR and HA remains intact.

4.1.3.  Proxy Handover Support

                    +----+        +-------+      +-------+      +-----+
                    |    |        | New   |      |  Old  |      |     |
                    | MN |        | AR /  |      |  AR / |      |  HA |
                    |    |        | PMA   |      |  PMA  |      |     |
                    +----+        +-------+      +-------+      +-----+
                       |               |             |             |
                       |     1         |             |             |
     Authentication    |<------------->|             |             |
                       |               |             |             |
                       |               |       2     |             |
                  +->  |               |-------------------------->|
     PMIP
     PMIPv4       |    |               |             |             |
                  |    |               |       3     |             |
                  +->  |               |<--------------------------|
                       |               |             |             |
                       |     4         |             |             |
     Data Forwarding   |<------------->|<=========================>|
                       |               |             |             |

                           Figure 3: AR Handover

   The AR handover procedure is described below.  There are three
   phases.  First, authentication and authorization happens happen when the
   mobile device attaches to the new AR in the network.  The successful
   authentication triggers the Proxy Mobile IPv4 signaling.  In the last
   phase, the forwarding path between the new AR and HA is set up for
   the mobile device to send and receive IP packets using the same Home
   Address anchored at the HA.

   1.  The mobile device establishes L2 link with the base station (not
       shown) and performs access authentication/authorization with the
       new
   AR AR, using the security method for network re-attachment.

   2.  Triggered by successful authentication, the PMA sends an a PRRQ to
       the HA.  The HA's IP address is typically obtained or is known typically by
       the method used for fast reauthentication re-authentication during AR handover (e.g.
       (e.g., context transfer between the two ARs).  Though ARs), though other
       methods may be used.  The PRRQ contains the CoA of the new PMA.
       The Home Address field is set to zero or the assigned IP address
       of the mobile device.  The IP address is also obtained/known by
       the same method mentioned before.

   3.  The home agent Home Agent updates the existing mobility binding entry for
       the mobile device upon processing the PRRQ.  The home agent Home Agent
       returns the Home Address, fetched from the binding, in the PRRP
       to the new PMA.  After the PMA processes the PRRP, the forwarding
       path for the Home Address between the new AR and HA is
       established.  The event completes the Proxy Mobile IPv4 signaling
       for AR handover.

   4.  At this step, which happens around the same time as step 2, the
       mobile device's IP stack may detect L2 link going down and up
       after access re-authentication.  The mobile device's IP stack may
       attempt to validate its IP address connectivity.  See ARP ([RFCARP])
   Section Sections
       6.1, ICMP ([RFCICMP]) Section 6.2 6.2, and DHCP ([RFC2131])
   Section 6.3 considerations of this document for details. considerations on ARP
       [RFCARP], ICMP [RFCICMP], and DHCP [RFC2131], respectively.
       Because the forwarding path is established between the new PMA
       and HA, the mobile device can receive or send IP packets using
       the Home Address.

4.1.4.  Resource Cleanup

                    +----+        +-------+      +-------+      +-----+
                    |    |        | New   |      |  Old  |      |     |
                    | MN |        | AR /  |      |  AR / |      |  HA |
                    |    |        | PMA   |      |  PMA  |      |     |
                    +----+        +-------+      +-------+      +-----+
                       |               |             |             |
                       |               |             |      1      |
                  +->  |               |             |<------------|
                  |    |               |             |             |
     Revocation   |    |               |             o 2           |
                  |    |               |             |             |
                  |    |               |             |      3      |
                  +->  |               |             |------------>|
                       |               |             |             |

            Figure 4: Registration Revocation for Previous PMA

   The resource cleanup procedure for the old AR is described below.
   This cleanup is necessary when the old AR needs to delete its PMIP PMIPv4
   and other associated states for the a mobile device that has moved to
   another AR.  Therefore, this is an optional procedure for Proxy
   Mobile IP.  The alternative method is based on the new PMA notifying
   the old PMA to clean up resources.  This  The alternative method is out of
   the scope of this document.

   1.  Triggered by the update of the mobility binding entry for a
       mobile device that has moved to a new AR, the HA may send a
       Registration Revocation (as specified in RFC 3543 [RFC3543]) to
       the old PMA (i.e. (i.e., specifically to the Foreign Agent entity) in
       order to clean up unused resources in an expeditious manner.

   2.  The old PMA removes the PMIP PMIPv4 states for the mobile device.

   3.  The old PMA sends revocation acknowledgement to the HA.

4.2.  Establishment of a Bi-Directional Tunnel

   The PMA and HA set up a tunnel between them for the Home Address
   after the PMIP PMIPv4 registration message exchange.

4.2.1.  Packet Forwarding

   The bi-directional tunnel between the PMA and the HA allows packets
   to flow in both directions, while the mobile device is connected on
   the visited network.  All traffic to and from the mobile device
   travels through this tunnel.

   While the PMA is serving a mobile device, it MUST be able to
   intercept all packets sent from the mobile device and forward them
   out the tunnel created for supporting that mobile device.  Typically,
   forwarding is based on Layer layer 2 information such as the source MAC Media
   Access Control (MAC) address or ingress interface.  This allows
   overlapping IP addresses to be supported for the packet from the
   mobile device.  For example, the PMA forwards packets from mobile
   devices with the same IP address are forwarded to the tunnel associated with each
   mobile device by the PMA device, based on the source MAC address.

   Any

   The PMA de-encapsulates any packets received on the tunnel from HA, the PMA de-encapsulates
   HA before forwarding to the mobile device on its link.  Typically,
   the forwarding is based on the destination IP address and ingress HA
   tunnel (which may have a GRE Key). key).  This allows overlapping IP
   addresses to be supported for the packet destined to the mobile
   device.  For example, the PMA forwards packets to mobile devices with
   the same IP address are forwarded to the link associated with each mobile device
   by the PMA device,
   based on the GRE Key key value of the tunnel created for the HA that
   serves these mobile devices.

   The tunnel operation between the PMA and HA is the same as between
   the FA and HA in RFC 3344.  The IP TTL, TTL (Time to Live), fragmentation,
   re-assembly, etc. logic remain the same.  The tunnel mode is IPinIP
   by default or GRE as an option.

4.2.2.  Broadcast and Multicast

   Broadcast packet processing for DHCP and ARP (Address Resolution
   Protocol) messages are described in Section 6.3 and Section 6.1,
   respectively.  For other types of broadcast packets, the PMA and HA
   process them in accordance to [RFC3344], [RFC3024], and [MIP4MCBC].
   Only the Direct Encapsulation Delivery Style is supported supported, as there
   is no encapsulation for the packets between the mobile device and
   PMA.

4.2.3.  Forwarding Between between Devices on same the Same PMA

   When the communication peers are both attached to the same PMA, the
   packet is forwarded as specified in Section 4.2.1.  The traffic
   between them are should be routed via the HA without taking a local
   shortcut on the PMA.  This ensures that data traffic data-traffic enforcement at
   the HA is not bypassed.

4.3.  Security Association Between between the PMA and the HA

   The security relationship for protecting the control message
   exchanges between the PMA and the HA may be either per node (i.e. (i.e.,
   same security association for all mobile devices) or per MN (i.e. (i.e.,
   unique security association per mobile device).  The method of
   obtaining the security association is outside of the scope of this
   document.

   For per node per-node SA support, the FA-HA Authentication Extension extension or IPSec IPsec
   (indicated in the PMIPv4 extension) is used to authenticate the
   signaling messages (including Registration Revocation [RFC3543])
   between PMA and HA.  In the case of IPSec, IPsec, Encapsulating Security
   Payload (ESP) [RFC4303] in transport mode with mandatory integrity
   protection should be used.  The IPSec IPsec endpoints are the IP addresses
   of the PMA and HA.

   For per MN per-MN SA support, the MN-HA Authentication Extension extension and/or MN-AAA MN-
   AAA Authentication Extension extension are used to authenticate the signaling.

   The creation of the security association may be assisted by the AAA
   server at the time of access authentication.

4.4.  Registration Sequencing

   The Identification field in the registration message provides replay
   protection and sequencing when the timestamp method is used.  This
   mechanism allows the HA to know the sequence of messages from the
   same PMA or different PMAs based on the Identification field.  The HA
   can also synchronize the PMA's clock by using the Identification
   mismatch error code in the proxy registration reply. Proxy Registration Reply.  This reply
   message would not be necessary when the PMA's clocks are synchronized
   using the Network Time Protocol [RFC1305] or some other method.  Note
   that the use of nonce for sequencing and replay protection is outside
   the scope of scope. this document.

   The method above is sufficient when there is a single source for
   signaling as in the split PMA case.  However  However, in the integrated PMA
   case, the proxy registration request Proxy Registration Request is sent from different sources
   (i.e.
   (i.e., different PMAs).  If the previous PMA is unaware that the
   mobile device has moved away and continues to send re-registration,
   then the HA would be misinformed on the location of the device.
   Therefore, an integrated PMA MUST confirm that the mobile device is
   still attached before sending a proxy registration request. Proxy Registration Request.

   Note that that, for the split PMA model as used in WiMAX Forum, see Forum (see
   Section 10, 10), the PMIP Client PMIPv4 client remains anchored during handover, see handover (see
   Section 10.1. 10.1).  In this case, the PMIP Client PMIPv4 client is the only source of
   the PRRQ.  However, there are cases such (such as PMIP Client PMIPv4 client relocation
   and uncontrolled handover event events) when more than one PMA performs
   registration.  The same method for the integrated PMA is used to
   ensure proper sequencing of registration on the HA.

4.5.  Mobile Device Interface Configuration

   Typically, the mobile device's interface needs to be configured with
   an IP address, network prefix, default gateway, and DNS server
   addresses before the network connection can be enabled to be used for
   communication.  For some IP stacks, the default gateway IP address
   has to be on the same subnet as the mobile device's IP address.  When
   the Home Agent's IP address is not on the same subnet as the Home
   Address, the vendor specific vendor-specific extensions (e.g. (e.g., [RFC4332]) or other
   methods MAY be used by the PMA to obtain the default gateway.

4.6.  Dynamic HA Discovery

   The PMA can perform dynamic HA discovery by sending the registration
   with Home Agent field set to 0.0.0.0 or 255.255.255.255.  The Home
   Agent responds with its IP address in the Home Agent field as
   specified in "Mobile IPv4 Dynamic HA Assignment Home Agent (HA) Assignment"
   [RFC4433].

5.  Proxy Mobile IPv4 Extensions

   The following PMIPv4 extensions are not required for base
   functionality but may be used in some cases where such features are
   applicable.  They are included before the authentication extension
   (e.g.
   (e.g., MN-HA or FA-HA authentication Authentication extension) in the registration
   message.

5.1.  PMIPv4 Per-Node Authentication Method Extension

   The Proxy Mobile IPv4 Authentication Method extension indicates
   alternative methods for authenticating the registration besides the
   default MN-HA Authentication Extension extension as specified in RFC 3344.
   This extension MUST be included in the Registration Request and
   Registration Reply when the security association for authenticating
   the message is between the PMA and HA on a per node per-node basis.  This
   means that a common key or set of keys (indexed by the SPI) are used
   for message authentication by the PMA and HA.  The key is independent
   of the mobile device device, which is identified in the registration.

      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      |   Sub-Type    |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Method     |
     +-+-+-+-+-+-+-+-+

              PMIPv4 Per-Node Authentication Method Extension

      Type

         47 (Proxy Mobile IPv4 Non-skippable Non-Skippable Extension)

      Sub-Type

         1 (PMIPv4 Per-Node Authentication Method)

      Length

         1

      Method

         An 8-bit field that specifies the authentication type for
         protecting the signaling messages.

         The values (0 - 255) will be are allocated and managed by IANA.  The
         following values are currently reserved for have been assigned to the below specified method
         types.

         0: Reserved

         1: FA-HA Authentication

         2: IPSec IPsec Authentication

5.2.  Proxy Mobile IPv4 Interface ID Extension

   The Proxy Mobile IPv4 Interface ID extension identifies the interface
   address of the device used to attach to the network.  The information
   MAY be included in the Registration Request when the PMA is aware of
   it.

     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      | Sub-Type      | Identifier ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       PMIPv4 Interface ID Extension

      Type

         147 (Proxy Mobile IPv4 Skippable Extension)

      Length

         The length of the extension in octets, excluding Type and
         Length fields.

      Sub-Type

         1 (PMIPv4 Interface ID)

      Identifier

         A variable-length octet sequence that contains an identifier of
         the interface.

5.3.  Proxy Mobile IPv4 Device ID Extension

   The Proxy Mobile IPv4 Device ID extension identifies the device used
   to connect to the network.  The information MAY be included in the
   Registration Request when the PMA is aware of it.

     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      | Sub-Type      |    ID-Type    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Identifier ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        PMIPv4 Device ID Extension
      Type

         147 (Proxy Mobile IPv4 Skippable Extension)

      Length

         The length of the extension in octets, excluding Type and
         Length fields.

      Sub-Type

         2 (PMIPv4 Device ID)

      ID-Type

         An 8-bit field that specifies the device ID type.

         The values (0 - 255) will be are allocated and managed by IANA.  The
         following values are currently reserved for have been assigned to the below specified device ID
         types.

         0: Reserved

         1: Ethernet MAC address

         2: Mobile Equipment Identifier (MEID)

         3: International Mobile Equipment Identity (IMEI)

         4: Electronic Serial Number (ESN)

      Identifier

         A variable-length octet sequence that contains an identifier of
         the type indicated by the ID-Type field.

5.4.  Proxy Mobile IPv4 Subscriber ID Extension

   The Proxy Mobile IPv4 Subscriber ID extension identifies the mobile
   subscription.  The information MAY be included in the Registration
   Request when the PMA is aware of it.

     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      | Sub-Type      |    ID-Type    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Identifier ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      PMIPv4 Subscriber ID Extension

      Type

         147 (Proxy Mobile IPv4 Skippable Extension)

      Length

         The length of the extension in octets, excluding Type and
         Length fields.

      Sub-Type

         3 (PMIPv4 Subscriber ID)

      ID-Type

         An 8-bit field that specifies the subscriber ID type.

         The values (0 - 255) will be are allocated and managed by IANA.  The
         following values are currently reserved for have been assigned to the below specified subscriber
         ID types.

         0: Reserved

         1: International Mobile Subscriber Identity (IMSI)

      Identifier

         A variable-length octet sequence that contains an identifier of
         the type indicated by the ID-Type field.

5.5.  PMIP  PMIPv4 Access Technology Type Extension

   The Proxy Mobile IPv4 Access Technology Type extension indicates the
   type of radio access radio-access technology on which the mobile device is
   attached.  This extension MAY be included in the Registration Request
   when the PMA is aware of the information.  The HA can provide
   mobility on the same access technology type for a mobile device with
   multiple interfaces interfaces, assuming each interface is connected on a
   different access technology type.  The HA does not include the
   extension in the associated Registration Reply.

     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      | Sub-Type      |   Tech-Type   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   PMIP

                  PMIPv4 Access Technology Type Extension

      Type

         147 (Proxy Mobile IPv4 Skippable Extension)

      Length

         2

      Sub-Type

         4 (Access Technology Type)

      Tech-Type

         An 8-bit field that specifies the access technology through
         which the mobile device is connected to the access network.

         The values (0 - 255) will be are allocated and managed by IANA.  The
         following values are currently reserved for have been assigned to the below specified access
         technology types.

         0: Reserved

         1: 802.3

         2: 802.11a/b/g

         3: 802.16e

         4: 802.16m

         5: 3GPP EUTRAN/LTE

         6: 3GPP UTRAN/GERAN
         7: 3GPP2 1xRTT/HRPD

         8: 3GPP2 UMB

6.  Appearance of Being at Home Network

   Since the Mobile Node is not aware of its mobility and does not
   participate in handover signaling, the network entities emulate the
   home network to the mobile device attached on the network.  From the
   mobile device's perspective, it operates as if it is were at the home
   network.  However, the network is directing the mobile device's
   traffic to and from its current location and will continue to do so
   when it moves to a new location.

   An unmodified mobile device on a shared link learns the MAC address
   of another host on the home network via ARP ([RFCARP]), obtains an IP
   address and other host configuration via DHCP ([RFC2131]), and sends
   link-local multicast and broadcast packets.  The network's response
   to the host is equivalent to the situation when a host is on the home
   network.  When the link state changes, some hosts use ARP, ICMP,
   and/or DHCP to detect if it has changed the point of attachment on
   the network.

6.1.  ARP Considerations

   For IEEE 802 type of access networks (e.g. (e.g., WLAN, WiMAX Ethernet
   Convergence Sublayer), the mobile device sends ARP request requests for the CN
   Corresponding Node (CN) and default gateway on the same network.  The
   purpose of maintaining an ARP entry is to allow the delivery of the
   packet from the mobile device to the CN using the destination MAC
   address.  The ARP procedure for resolving IP and MAC address mapping
   is not needed for 3GPP2's cdma2000 and WiMAX IP Convergence Sublayer
   networks.

   The access router is always the L2 endpoint for the mobile device.
   The destination MAC address in the packet does not need to be set to
   the CN's MAC address.  As long as the packet can be received by the
   access router, it will be forwarded toward the CN via the home
   network node (further details in Section 4.2.1).  The ARP table in
   the mobile device does not need to be populated with CNs' MAC
   addresses in order for the packet to reach the CNs.

   A mobile device has ARP entries for the default gateway and hosts on
   the same subnet.  Regardless of what the MAC addresses are, the AR
   receives the packets sent from the mobile device.

6.2.  ICMP Considerations

   For movement detection, certain types of network stack on the mobile
   device will send an ICMP request [RFCICMP] to the default gateway
   after detecting the link went down and up.  The IP TTL in the message
   is set to 1 to check if the default gateway is still directly
   reachable on the access network.  The PMA MAY send an ICMP reply when
   it is providing Proxy Mobile IPv4 service for the mobile device.
   This response confirms to the mobile device that it has remained on
   the home network after link state change.  This behavior is observed
   on existing client implementation.  Detecting  "Detecting Network Attachment in
   IPv4 (DNAv4)" [RFC4436] can be employed.

   General ICMP traffic is handled as normal IP packets and tunneled
   between the PMA and HA.

6.3.  DHCP Considerations

   DHCP [RFC2131] is used to obtain an IP address and other host
   configuration parameters for a mobile device.  The mobile device is
   expected to behave as a normal DHCP client when connected to the
   network with Proxy Mobile IPv4 service.  There are two DHCP phases:
   bootup and renewal/release.  The bootup procedure relies on the DHCP
   relay agent to obtain a lease on the IP address for the DHCP client
   from the DHCP server.  The DHCP client directly renews and releases
   the lease with the DHCP server.

   In Proxy Mobile IPv4, the mobile device boots up on a network that is
   not the home network associated with the leased IP address.  Also,
   the mobile device can move to other networks that are not related to
   that IP address.  Yet, the DHCP client on the mobile device continues
   to operate as a stationary device that is directly on the network
   associated with its IP address.  The PMA and HA create the
   transparency of the remote home network and mobility events by
   providing the expected network response to the DHCP client.

   There are several methods for the network infrastructure to interface
   with the mobile device such that the mobile device believes it is
   always fixed on the same network.  The following methods are
   identified here, though others may be used as well: well.

   DHCP Server in the AR:

      The mobile device boots up and initiates DHCP.  The procedure is
      described in Figure 1.  The DHCP client renews or releases the IP
      address directly with the DHCP server in the AR.  When the mobile
      device is on a different AR than the AR/DHCP server, the DHCP
      message from the client needs to be able to either be forwarded to
      the DHCP server in the previous AR or handled by the DHCP server
      in the new AR.  When the DHCP lease time expires for the mobile
      device's IP address or the DHCP release message is received on the
      current AR, the AR sends PMIPv4 de-registration to the HA.

   DHCP Relay Agent in the AR:

      The mobile device boots up and initiates DHCP.  The procedure is
      described in Figure 1.  The DHCP client renews or releases the IP
      address directly with the DHCP server in the HA.  When the mobile
      device is on a different AR, the DHCP message messages from the client are
      relayed to the DHCP server in the HA.  When the DHCP lease time
      expires for the mobile device's IP address or the DHCP release
      message is received on the HA, the HA deletes the mobility binding
      entry for the mobile device and sends registration revocation
      [RFC3543] to the AR.

6.4.  PPP IPCP Considerations

   When the mobile device access accesses the network via PPP [RFC1548], [RFC1661], LCP
   (Link Control Protocol) CHAP is used to authenticate the user.  After
   authentication, the NAS (which is the AR/PMA) sends the proxy Proxy Mobile
   IPv4 Registration Request to the HA.  The HA responds with the Home
   Address in the
   proxy Proxy Registration Reply.  The NAS informs the mobile
   device to use the Home Address during IPCP [RFC1332].  When the
   mobile device moves to a new NAS, the same procedure happens and that
   mobile device has the same IP address for communication.

   The message exchange is illustrated in Figure 1.

6.5.  Link-Local Multicast and Broadcast Considerations

   Depending on configuration policies, the PMA may tunnel all packets
   destined to Link-Local Multicast or Broadcast to the HA.  The HA
   looks up the hosts which that are in the same subnet and send sends a duplicated
   packet to each of them.

7.  Proxy Mobility Agent Operation

   The PMA performs the functions of a Mobile Node entity as described
   in RFC 3344 3344, with the exceptions identified below.

   -  No agent discovery (i.e. (i.e., agent solicitation and advertisement) is supported
      supported.

   -  The D-bit (De-encapsulation by MN) in the Registration Request is
      always set to zero zero.

   The main responsibility of the PMA is to set up and maintain the
   routing path between itself and the HA for a mobile device that is
   attached on the network.  When it detects a mobile device is no
   longer attached, the routing path is torn down.  It is possible that
   the PMA functions may be split up in implementations such as WiMAX
   (Section 10).

   The PMA needs to know the following information information, at a minimum minimum, for
   sending a proxy registration:

   1.  NAI of the mobile device device.

   2.  MN-HA security association association, when per-mobile device security
       association is used used.

   3.  FA-HA Mobility Security Association security association or IPSec Security Association IPsec security association
       when per-node security association is used.  Note,  Note that these
       associations are specific only between PMA and HA, and are
       cryptographically unrelated to the associations between the MN
       and other network nodes.

   4.  HA Address

   The Address.

   This information is typically downloaded from the AAA server during
   access authentication.

8.  Home Agent Operation

   The Home Agent has the functionality as described in RFC 3344 [RFC3344].
   In addition, the following features are introduced by Proxy Mobile
   IPv4:

   1.  Sequencing between PRRQs from multiple PMAs.  For the integrated
       PMA case, there is a period after handover that may result in
       both the new PMA and old PMA sending PRRQs.  It is imperative
       that the old PMA confirm that the mobile device is attached
       before sending a PRRQ when the re-registration timer expires.
       This would ensure that the HA only receives registration from the
       PMA that is serving the mobile device.

   2.  Authentication of PRRQs based on per Node Security Association per-node security associations
       (FA-HA AE or IPsec AH/ESP) is applicable in the integrated PMA
       case.  The presence of MN-HA AE or MN-AAA AE in the PRRQ is not
       necessary in this case.  Since PMIP PMIPv4 is based on signaling
       between the PMA and the HA, the security for the message can be
       authenticated based on the peers' relationship.  The HA can
       authorize PMIP PMIPv4 service for the mobile device at the PMA by
       contacting the AAA server.

   3.  The ability to process the Proxy Mobile IPv4 Extensions extensions defined
       in this document for enhanced capabilities of PMIP. PMIPv4.

8.1.  Processing Proxy Registration Requests

   When a proxy registration request a Proxy Registration Request is received, the HA looks up the
   mobility binding entry indexed by the NAI.  If the entry exists, HA
   compares the Sequence Numbers sequence numbers between the message and mobility
   binding entry (MBE), if present.  If the value in the message is zero
   or greater than or equal to the one in the MBE, HA accepts the
   registration.  The HA replies with a sequence number that is one
   greater than the larger value of either the MBE or Proxy Registration
   Request.  If the registration is denied, then HA sends error code
   "Administratively prohibited (65)".  If the HA is not enabled with
   Proxy Mobile IPv4 or it cannot process the Proxy Mobile IPv4 Extensions
   defined in this document, it sends a registration reply Registration Reply with error
   code PMIP_UNSUPPORTED (Proxy ("Proxy Registration not supported by the HA). HA").
   In the case when the PMA is not allowed to send a proxy
   registration request Proxy Registration
   Request to the HA, the HA sends a proxy registration
   reply Proxy Registration Reply with error
   code PMIP_DISALLOWED (Proxy ("Proxy Registrations from this PMA is are not allowed).
   allowed").

   A PMA receiving these error codes SHOULD not NOT retry sending proxy Proxy
   Mobile IPv4 messages to the HA that sent replies with these error
   codes.

9.  Mobile Device Operation

   As per this specification, a mobile device would function as a normal
   IPv4 host.  The required behavior of the node will be consistent with
   the base IPv4 specification [1]. [RFC0791].  The mobile station will have
   the ability to retain its IPv4 address as it moves from one point of
   network attachment to the other without ever requiring it to
   participate in any mobility related mobility-related signaling.

   When booting up for the first time, a mobile device obtains an IPv4
   address using DHCP or IPCP.

   As the mobile device roams, it is always able to communicate using
   the obtained IP address on the home network.  The PMA on the
   currently attached network signals to the HA to ensure a proper
   forwarding path for the mobile device's traffic.

9.1.  Initial Network Access

   When the mobile device accesses the network for the first time and
   attaches to a network on the PMA, it will present its identity in the
   form of an NAI to the network as part of the network access network-access
   authentication process.

   Once the address configuration is complete, the mobile device will
   always be able to use that IP address anywhere in the network.

9.2.  Mobile Device Mobility

   When a mobile device moves to a new PMA from another PMA, the
   following occurs:

   The mobile device may perform a network access network-access authentication with
   the new AR/PMA.  If the authentication fails, the mobile device will
   not be able to use the link.  After a successful authentication, the
   new PMA will have the identifier and the other profile data of the
   mobile device.  The new PMA can also obtain the mobile device's
   information using a context transfer mechanism context-transfer mechanism, which is out of the
   scope of this document.

   Once the network access network-access authentication process is complete, the
   mobile device may sense a change in the Link Layer and use ARP, DHCP,
   and/or ICMP to detect if it is still on the same subnet.  These
   mechanisms are handled by the network as described in "Appearance of
   Being At Home Network" (Section 6) section. 6).

9.3.  Sending and Receiving Packet Packets

   All packets that are to be sent from the mobile device to the
   Corresponding Node (CN) will be sent as normal IPv4 packets packets, setting
   the Source Address of the IPv4 header to the Home Address and the
   Destination Address to the corresponding node's Corresponding Node's IP address.  In proxy Proxy
   Mobile IPv4 operation, the default gateway for the mobile device is
   set up to reach the PMA.

   Similarly, all packets sent to the mobile device's IP Address address by the
   corresponding node
   Corresponding Node will be received by the mobile device in the
   original form (without any tunneling overhead).

   For Proxy Mobile IP, the packet from the mobile device is transported
   to the HA to reach the destination destination, regardless of the destination IP
   address.  For a CN with an IP address on the same network as the
   mobile device but that is physically located elsewhere, the HA will
   tunnel the packet to the CN.  Otherwise, the HA forwards the traffic
   via normal routing.

   No special operation is required by the mobile device to either send
   or receive packets.

   Mobile devices attached to the same PMA may be using different HAs
   for transporting their traffic.

10.  Proxy Mobile IPv4 Use Case in WiMAX

   WiMAX Forum Network Working Group (NWG) uses the Proxy Mobile IPv4
   scheme to provide IPv4 connectivity and IP mobility.  The relevant
   specification from WiMAX Forum is [NWG].

   The Proxy Mobile IPv4 protocol is used over NWG reference point 3
   (R3).  Most of the Proxy Mobile IPv4 related procedures and
   requirements are described in reference to mobility management over
   R3.

   The Proxy Mobile IPv4 use case in the WiMAX Forum specification is
   illustrated in the following diagram:

                                            |
                                            |            CSN
                                            |
                                            |
                     +-------+              |            +-------+
                     |       |              |            |       |
                     |AAAV   |--------------|------------| AAAH  |
                     |       |              |            |       |
                     |       |              |            |       |
                     +-------+              |            +-------+
                          |                 |                |
                          |                 |                |
                          |                 |                |
                  +------------------+      |                |
                  |   +-------+      |      |                |
                  |   | NAS   |      |      |                |
                  |   | PMIP  | ASN1 |      |                |
                  |   | Client|      |      |                |
                  |   +-------+      |      |                |
                  |       |          |      |                |
                  |       | R4       |      |                |
                  |   +-------+      |      |             +------+
         +----+   |   | FA,   |      |      |    PMIPv4   |      |
         | MN |-------| DHCP  |---------------------------|  HA  |
         +----+   |   | Relay/|      |      |     R3      |      |
                  |   | Server| ASN2 |      |             +------+
                  |   +-------+      |      |
                  |                  |      |
                  +------------------+
                     Split PMA

         Figure 5: WiMAX NWG network configuration Network Configuration for PMIP use PMIPv4 Use

   As shown in the figure above, WiMAX NWG uses the split PMA model.
   The PMIP Client PMIPv4 client is collocated with the NAS in ASN1 (a.k.a. (aka,
   Authenticator ASN).  The NWG architecture divides the network into
   two parts.  The Access part is termed as Access the "Access Service Network Network"
   (ASN).  The Core part is termed as Connectivity the "Connectivity Service Network Network"
   (CSN).  The MN attaches to a an 802.16 radio in the ASN2 (aka (aka, Anchor
   Data Path Function).  The radio (base station) connects to the Anchor
   Data Path Function (A_DPF) in ASN2 ASN2, which in turn connects to the
   Authenticator ASN (NAS) in ASN1.  ASN1 authenticates and authorizes
   the MN.  The AAA infrastructure is used to authenticate and authorize
   the MN.

   Note that, during initial network entry by the MN, the PMA can be an
   integrated PMA with all the functions collocated in ASN1.  Due to
   mobility, the FA part of the PMA may have to be relocated to a more
   optimized location for better bearer management.  However, to
   describe the WiMAX specific use case for Proxy Mobile IPv4, we will
   use the split PMA model since it is a more generic representation of
   the WiMAX NWG mobility framework.

   The WiMAX NWG specification [NWG], [NWG] defines a key bootstrapping scheme
   for use with proxy Proxy Mobile IPv4.  The specification uses per MN per-MN
   security association for proxy Proxy Mobile IPv4 operation.  The relevant
   keys (e.g. (e.g., MN-HA key) are derived using EAP authentication as
   specified in this document.  For more information, please refer to section
   Section 4.3 of [NWG], stage-3 specification.

   Mobile IPv4 Registration Revocation is optionally supported in WiMAX.
   The security association for this is per Node. node.  It is provided with
   FA-HA AE.  The FA-HA key is also bootstrapped via the same key
   hierarchy that is described in section Section 4.3 of [NWG].

   The proxy Proxy Mobile IPv4 operation in WiMAX NWG is aligned with the
   basic proxy Proxy Mobile IPv4 operation as described in section Section 4 of this
   document.  There are specific considerations for WiMAX NWG 1.0.0 use
   of proxy Proxy Mobile IPv4.  These are listed below:

   1.  Use of per MS per-MS SA for proxy Proxy Mobile IPv4 registration.  In this
       case, MN-HA AE is used.

   2.  Use of split PMA to handle FA relocation while PMIP Client the PMIPv4 client
       remains anchored with the NAS (Authenticator ASN).

   3.  Only the Proxy Mobile IPv4 Access Technology Type Extension extension
       defined in this document is used in the NWG specification [NWG].

   4.  GRE key identifier is optionally used between the HA and the PMA.

   5.  The PMIP Client PMIPv4 client and the FA interact via the WiMAX specific
       reference point and protocol (aka (aka, R4).  For more information information,
       please refer to the NWG specification [NWG].

   6.  In order to handle inter ASN inter-ASN (inter Access Router) handover, handover and
       still allow the MN to use the same DHCP server's IP address that
       was sent in DHCPOFFER/ACK, the DHCP server (aka (aka, proxy) functions
       in the ASN is are required to be configured with the same IP
       address.

   7.  The MN - AR (trigger for proxy Proxy Mobile IPv4) interaction is based
       on DHCP.  DHCPDISCOVER from the MN triggers proxy the Proxy Mobile IPv4
       process in the ASN.

10.1.  Proxy Mobile IPv4 Call Flow Examples with Split PMA in WiMAX

   Since the WiMAX uses the split PMA model, the call flows involve WiMAX
   proprietary signaling between PMIP Client the PMIPv4 client and FA within the
   PMA.  The following call flows illustrate this.

   Proxy Handover Operation in WiMAX with Split PMA

                     Split PMA
                     +-----------------------------------+
            +----+   | +------+     +------+     +-----+ |    +-----+
            |    |   | | NAS/ |     |  Old |     | New | |    |     |
            | MN |   | | PMIP |     |  FA  |     |  FA | |    | HA  |
            |    |   | |Client|     |      |     |     | |    |     |
            +----+   | +------+     +------+     +-----+ |    +-----+
               |     +----|------------|------------|----+       |
               |          |            |       PMIP Tunnel       |
               |          |            |<=======================>|
               |          |            |            |            |
               |          |            |  R4 tunnel |            |
               |          |            |<==========>|            |
               |          |       1    |            |            |
               |<---------------------------------->|            |
               |          |            |            |            |
               |          |            |     2      |            |
               |          |            |<---------->|            |
               |          |       3    |            |            |
               |          |<----------------------- |            |
               |          |            |            |            |
               |          |       4    |            |            |
          +->  |          |------------------------>|            |
          |    |          |            |            |     5      |
          |    |          |            |            |----------->|
          |    |          |            |            |            |
   PMIP   |    |          |            |            |     6      |
          |    |          |            |            |<-----------|
          |    |          |            |            |            |
          |    |          |       7    |            |            |
          +->  |          |<------------------------|            |
               |          |            |            |            |
               |          |            |     8      |            |
               |          |            |<---------->|            |
               |          |            |            |            |
               |     9    |            |            |PMIP Tunnel |
   Data        |<---------------------------------->|<==========>|
   Forwarding  |          |            |            |            |

        Figure 5: AR 6: Proxy Handover Operation in WiMAX with Split PMA
   In this scenario, the MN has moved to a new FA's area (known as the
   Data Path Function in WiMAX).  The old FA and the new FA interact
   with each other and also with the PMIP Client PMIPv4 client over WiMAX a WiMAX-
   specified R4 reference point to perform the handover.  The steps are
   described below:

   1.  The mobile device establishes a L2 link with a base station (not
   shown)
       shown), which connects to a new FA (aka (aka, new Data Path Function
       in WiMAX).  Note that that, in this case, the MN does not perform
       authentication and authorization.  The PMIP Tunnel PMIPv4 tunnel remains
       between the Old old FA (aka (aka, old Data Path Fucntion Function in WiMAX).  The
       data flows through PMIP the PMIPv4 tunnel between the HA and the old FA
       FA, and through the WiMAX
   specific WiMAX-specific R4 tunnel between the old FA
       and the new FA and from the new FA to the MN.

   2.  The new FA interacts with the old FA using WiMAX specific a WiMAX-specific R4
       reference point to initiate the handover process.

   3.  The new FA uses the WiMAX specific WiMAX-specific R4 reference point to request
       the PMIP Client PMIPv4 client to begin the PMIP PMIPv4 handover.

   4.  Triggered by step 3 3, the PMIP Client PMIPv4 client sends an a PRRQ to the new
       FA.  The PRRQ contains the FA-CoA of the new FA.  The Home
       Address field is set to the address of the assigned IP address of
       the mobile node. Mobile Node.  The PRRQ is embedded in the WiMAX specific WiMAX-specific R4
       packet.

   5.  The new FA forwards the PRRQ to the HA.

   6.  The home agent Home Agent updates the existing mobility binding entry for
       the mobile device upon processing the PRRQ.  The home agent Home Agent
       responds back to the new FA with PRRP.

   7.  The new FA forwards the PRRP after encapsulating it in a WiMAX WiMAX-
       specific R4 packet to the PMIP Client. PMIPv4 client.

   8.  The new FA and the old FA exchange WiMAX WiMAX-specific R4 specific messages
       between them to confirm the handover.  The old FA cleans up it's its
       resources for the MN.  The R4 bearer forwarding also stops at
       this point.

   9.  The forward and reverse direction traffic flows via the new FA.
       The handover is complete at this point.

11.  Proxy Mobile IPv4 Use Case in 3GPP2

   3GPP2 uses the Proxy Mobile IPv4 scheme to provide mobility service
   for the following scenarios (as shown in the figures below):

   1.  Mobility between the Base Station base station (BS) and Access Gateway access gateway (AGW)

   2.  Mobility between the AGW and the Home Agent (HA).

   As shown in the diagrams below below, in use case 1, the BS acts as the PMA
   and the AGW acts as the HA for proxy Proxy Mobile IPv4 operation.  In use
   case 2, the AGW acts as the PMA while the HA assumes the role of the
   home agent.
   Home Agent.

                     RAN                            Core

                  +-------+                       +------+
      +----+      | BS/   |             PMIPv4    |      |
      | MN |------| PMA   |-----------------------| AGW/ |
      +----+      |       |                       |  HA  |
                  |       |                       +------+
                  +-------+

                Integrated PMA

      Figure 7: 3GPP2's PMIP4 use case PMIPv4 Use Case 1 - BS-AGW interface mobility Interface Mobility

                     RAN                            Core

                  +-------+                       +------+
      +----+      | AGW/  |             PMIPv4    |      |
      | MN |------| PMA   |-----------------------|  HA  |
      +----+      |       |                       |      |
                  |       |                       +------+
                  +-------+

                Integrated PMA

      Figure 8: 3GPP2's PMIP4 use case PMIPv4 Use Case 2 - AGW-HA interface mobility Interface Mobility

   The figure below shows a simplified 3GPP2 architecture.  For details details,
   please refer to the 3GPP2 Converged Access Network (CAN) architecture
   ([3GPP2]).

                           RAN                    Core
                 -----------^------------   -------^-------------
                |                        | |                     |
                V                        V V                     V

                  +------+            +------+           +-----+
      +----+      |      |  PMIPv4    |      |  PMIPv4   |     |
      | MN |------| BS   |------------| AGW  |-----------| HA  |
      +----+      |      |            |      |           |     |
                  +------+            +------+           +-----+

                  Figure 9: Simplified 3GPP2 Architecture

   The Proxy Mobile IPv4 usage scenario in 3GPP2 (case 1) is illustrated
   in the following diagram:

         +----+        +-------+      +-------+   +------+
         |    |        |       |      |       |   |      |
         | MN |        |  BS/  |      | HAAA  |   | AGW/ |
         |    |        |  PMA  |      |       |   | HA   |
         +----+        +-------+      +-------+   +------+
           |               |             |          |
           |     1a        |     1b      |          |
           |<------------->|<----------->|          |
           |               |             |          |
           |     2         |             |          |
           |-------------->|             |          |
           |               |       3     |          |
           |               |----------------------->|
           |               |             |          |
           |               |       4     |          |
           |               |<-----------------------|
           |     5         |             |          |
           |<--------------|             |          |
           |               |             |          |
           |     6         |             |          |
           |<======================================>|
           |               |             |          |

             Figure 10: Network Connection Setup (use case 1)

   Description of the steps:

   1a.  MN performs laye layer 2 establishment with the BS/PMA and performs
        access authentication/authorization.  During this phase, the MN run
        runs EAP over UMB. Ultra Mobile Broadband (UMB).  The BS acts as the
        NAS in this phase.

   1b.  The BS exchanges AAA messages with the home Home AAA server via the
        AR (not shown in the figure) to authenticate the MN.  As part of
        this step, the AR may download some information about the MN (e.g.
        (e.g., user's profile, handset type, assigned home agent Home Agent
        address, and other capabilities of the MN).  This information is
        passed to the PMA/BS (as necessary) to setup set up the PMIP PMIPv4 tunnel
        in the next step(s).

   2.   The MN sends layer 2 signaling messages to the BS/PMA to trigger
        the PMIP PMIPv4 tunnel setup process.

   3.   Triggered by step 2 2, the PMA/BS sends a PRRQ to the AGW/HA.  The
        HA's address is either received at step 1b from the Home AAA
        server (HAAA) or is discovered by other means.  The PRRQ
        contains the Care-of Address (CoA) of the PMA (collocated FA in
        this case).  The HoA field is set to all zeros (or all ones).
        The PRRQ is protected by the method described in this document.
        The derivation and distribution of the MN-HA or FA-HA key is
        outside the scope of this document.

   4.   The AGW/HA registers the MN's session, assigns a symmetric GRE
   key
        key, and returns this key in the PRRP to the BS/PMA.

   5.   The BS/PMA responds back to the MN with a layer 2 signaling
        message.

   6.   At this step, the MN is assigned an IP address and is connected
        to the network (via the AGW).

   In use case 2 2, the same procedures are followed except the PMIPv4
   tunnel is established between the AGW and the HA.  In this case case, GRE
   tunneling may not be used.

11.1.  HO considerations  Handover Considerations in 3GPP2

   There are some special handover considerations in 3GPP2's Proxy
   Mobile IPv4 use case.  Below is an illustration of the specific use
   case:

      +----+        +-------+      +-------+   +-------+
      |    |        |       |      |       |   |       |
      | MN |        | New   |      |  AGW/ |   | Old   |
      |    |        | PMA/BS|      |  HA   |   | PMA/BS|
      +----+        +-------+      +-------+   +-------+
        |               |              |          |
        |               |      1       |          |
        |               |------------->|          |
        |               |              |          |
        |               |              |          |
        |               |              o 2        |
        |               |              |          |
        |               |              |          |
        |               |      3       |          |
        |               |<-------------|          |
        |               |              |          |
        |               |              |          |
        |               |         4    |          |
        |               |<----------------------->|
        |               |              |          |
        |               |              |          |
        |               |              |          o  5
        |               |              |          |
        |               |              |          |

         Figure 11: 3GPP2 Registration Revocation for Previous PMA

   Description of the steps:

   1.  MN attaches to the new BS (L2 gets established).  There is an
       ongoing mobility binding entry (MBE) in the AGW for the MN.  The
       PMA in the new BS sends a PRRQ to the AGW.

   2.  The AGW receives a Proxy Registration Request for a Mobile Node
       and detects that it has an existing Mobility Binding Entry (MBE).
       The AGW validates the PRRQ from the new BS and it updates the MBE
       for the MN.  The MBE is kept tentative at this point.

   3.  The AGW sends a Proxy Registration Reply to the new BS.  No
       Registration Revocation is used in the 3GPP2's use case.

   4.  A 3GPP2's proprietary PMA movement notification message may be
       exchanged between the AGW and the old BS.

   5.  The MBE update with the new BS is committed at this step.

12.  IANA Considerations

   This specification registered registers 47 for the Proxy Mobile IPv4 Non-
   skippable
   Non-Skippable Extension and 147 for Proxy Mobile IPv4 Skippable Extension
   Extension, both of which are described in Section 5.  The ranges for
   Mobile IPv4 [RFC3344] extension types are defined at http://www.iana.org/assignments/mobileip-numbers.
   http://www.iana.org.  This specification also creates a new subtype
   space for the type number of the extensions.  The subtype value 1 is
   defined for the PMIPv4 Non-skippable Non-Skippable Extension.  The subtype values 1
   to 4 are defined for the PMIPv4 Skippable Extension.  Similar to the
   procedures specified for Mobile IPv4 number spaces, future
   allocations from the number space require expert review [RFC5226].

   The PMIPv4 Per-Node Authentication Method Extension, extension defined in
   Section 5.1 of this document, introduces a new authentication method
   numbering space, where the values from 0 to 2 have been reserved by assigned per
   this document.  Approval of new Access Technology type values are to
   be made through IANA Expert Review.

   The PMIPv4 Device ID Extension, extension defined in Section 5.3 of this
   document, introduces a new ID type numbering space, where the values
   from 0 to 4 have been reserved by assigned per this document.  Approval of new
   Access Technology type values are to be made through IANA Expert
   Review.

   The PMIPv4 Subscriber ID Extension, extension defined in Section 5.4 of this
   document, introduces a new ID type numbering space, where the values
   from 0 to 1 have been reserved by this document.  Approval of new
   Access Technology type values are to be made through IANA Expert
   Review.

   The PMIPv4 Access Technology Type Extension, extension defined in Section 5.5 of
   this document, introduces a new technology type numbering space,
   where the values from 0 to 8 have been reserved by this document.
   Approval of new Access Technology type values are to be made through
   IANA Expert Review.

12.1.  Mobile IPv4 Extension Types

   This document introduces the following Mobile IP extension types.

   Name       : Proxy Mobile IPv4 Non-skippable Non-Skippable Extension
   Type Value : 47
   Section    : 5

   Name       : Proxy Mobile IPv4 Skippable Extension
   Type Value : 147
   Section    : 5

12.2.  Mobile IPv4 Error Codes

   This document introduces the following error code that can be
   returned by the HA in a Proxy Registration Reply.

   Name                    Value    First referenced
   ----                    -----    ----------------
   PMIP_UNSUPPORTED         149     Section 8.1 of RFC 5563
   PMIP_DISALLOWED          150     Section 8.1 of RFC 5563

13.  Security Considerations

   The functionality in this document is protected by the Authentication
   Extensions authentication
   extensions described in RFC 3344 [RFC3344] or IPSec IPsec [RFC4301].  Each
   PMA needs to have an security association (e.g. (e.g., MN-HA, FA-HA, IPSec IPsec
   AH/ESP) with the HA to register the MN's IP address.  The security
   association can be provisioned by the administrator, administrator or dynamically
   derived.  The dynamic key derivation and distribution for this scheme
   is outside the scope of this document.

14.  Acknowledgements

   The authors would like to thank the following individuals for their
   review, comments, and suggestions to improve the content of this
   document.

   Shahab Sayeedi (Motorola), Alper Yegin (Samsung), Premec Domagoj
   (Siemens), Michael Hammer (Cisco), Jun Wang (Qualcomm), Jayshree
   Bharatia (Nortel), Semyon Mizikovsky (Alcatel-Lucent), Federico De
   Juan Huarte (Alcatel-Lucent), Paula Tjandra (Motorola), Alice Qinxia
   (Huawei), Howie Koh (Greenpacket), John Zhao (Huawei), Pete McCann
   (Motorola), and Sri Gundavelli (Cisco).

15.  References

15.1.  Normative References

   [3GPP2]      "3GPP2 Basic IP Service for Converged Access Network",
                X.S0054-100-0 Version 2.0, August 2008.

   [DSMIPv4]  Tsirtsis, G., "Dual Stack Mobile IPv4",
              draft-ietf-mip4-dsmipv4-06.txt (work in progress),
              February 2008.

   [MIP4GREKEY]
              Yegani, P., "GRE Key Extension for Mobile IPv4",
              draft-yegani-gre-key-extensions-03.txt (work in progress),
              Jun 2007.

   [MIP4MCBC]
              Chakrabarti, S., "IPv4 Mobility extension for Multicast
              and Broadcast Packets", draft-chakrabarti-mip4-mcbc-02.txt
              (work in progress), Nov 2007.

   [NWG]        "WiMAX Forum Network Architecture (Stage 3: Detailed
                Protocols and Procedures) Procedures)" Release 1 1, Version 1.2.3",  ,
              Jul 1.2.3,
                July 2008.

   [RFC1305]  Mills, D., "Network Time Protocol (Version 3)
              Specification, Implementation", RFC 1305, March 1992.

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

   [RFC1548]  Simpson, W., "The Point-to-Point Protocol (PPP)",
              RFC 1548, December 1993.

   [RFC1994]  Simpson, W., "PPP Challenge Handshake Authentication
              Protocol (CHAP)", RFC 1994, August 1996.

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

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

   [RFC2484]  Zorn,

   [RFC3024]    Montenegro, G., "PPP LCP Internationalization Configuration
              Option", Ed., "Reverse Tunneling for Mobile IP,
                revised", RFC 2484, 3024, January 1999.

   [RFC3024]  Montenegro, 2001.

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

   [RFC3543]    Glass, S. and M. Chandra, "Registration Revocation in
                Mobile IPv4", RFC 3543, August 2003.

15.2.  Informative References

   [MIP4GREKEY] Yegani, P., "GRE Key Extension for Mobile IPv4", Work in
                Progress, June 2007.

   [MIP4MCBC]   Chakrabarti, S., "IPv4 Mobility extension for Multicast
                and Broadcast Packets", Work in Progress, November 2007.

   [RFC0791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
                September 1981.

   [RFC1305]    Mills, D., "Network Time Protocol (Version 3)
                Specification, Implementation and Analysis", RFC 1305,
                March 1992.

   [RFC1332]    McGregor, G., "Reverse Tunneling for Mobile IP,
              revised", "The PPP Internet Protocol Control
                Protocol (IPCP)", RFC 3024, January 2001.

   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", 1332, May 1992.

   [RFC1661]    Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
                STD 51, RFC 3344,
              August 2002.

   [RFC3543]  Glass, S. and M. Chandra, "Registration Revocation in
              Mobile IPv4", 1661, July 1994.

   [RFC1994]    Simpson, W., "PPP Challenge Handshake Authentication
                Protocol (CHAP)", RFC 3543, 1994, August 2003. 1996.

   [RFC3748]    Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
                H. Levkowetz, Ed., "Extensible Authentication Protocol
                (EAP)", RFC 3748, June 2004.

   [RFC4058]    Yegin, A., Ed., Ohba, Y., Penno, R., Tsirtsis, G., and
                C. Wang, "Protocol for Carrying Authentication for
                Network Access (PANA) Requirements", RFC 4058, May 2005.

   [RFC4301]    Kent, S. and K. Seo, "Security Architecture for the
                Internet Protocol", RFC 4301, December 2005.

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

   [RFC4332]    Leung, K., Patel, A., Tsirtsis, G., and E. Klovning,
                "Cisco's Mobile IPv4 Host Configuration Extensions", RFC
                4332, December 2005.

   [RFC4433]    Kulkarni, M., Patel, A., and K. Leung, "Mobile IPv4
                Dynamic Home Agent (HA) Assignment", RFC 4433, March
                2006.

   [RFC4436]    Aboba, B., Carlson, J., and S. Cheshire, "Detecting
                Network Attachment in IPv4 (DNAv4)", RFC 4436, March
                2006.

   [RFC5213]    Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
                Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC
                5213, August 2008.

   [RFC5226]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
                IANA Considerations Section in RFCs", BCP 26, RFC 5226,
                May 2008.

   [RFC5454]    Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack
                Mobile IPv4", RFC 5454, March 2009.

   [RFCARP]     Plummer, D., "An Ethernet "Ethernet Address Resolution Protocol", Protocol: Or
                Converting Network Protocol Addresses to 48.bit Ethernet
                Address for Transmission on Ethernet Hardware", STD 37,
                RFC 826, November 1982.

   [RFCICMP]    Postel, J., "Internet Control Message Protocol", STD 5,
                RFC 792, September 1981.

Authors' Addresses

   Kent Leung
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   US

   Email:

   EMail: kleung@cisco.com

   Gopal Dommety
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   US

   Email:

   EMail: gdommety@cisco.com

   Parviz Yegani
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   US

   Email:

   EMail: pyegani@cisco.com

   Kuntal Chowdhury
   Starent Networks
   30 International Place
   Tewksbury, MA  01876
   USA

   Email:

   EMail: kchowdhury@starentnetworks.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.