GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5563

Independent Submission K. Leung Request for Comments: 5563 G. Dommety Category: Informational Cisco Systems ISSN: 2070-1721 P. Yegani

                                                      Juniper Networks
                                                          K. Chowdhury
                                                      Starent Networks
                                                         February 2010
               WiMAX Forum / 3GPP2 Proxy Mobile IPv4

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.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This is a contribution to the RFC Series, independently of any other
 RFC stream.  The RFC Editor has chosen to publish this document at
 its discretion and makes no statement about its value for
 implementation or deployment.  Documents approved for publication by
 the RFC Editor are not a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc5563.

Leung, et al. Informational [Page 1] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

Copyright Notice

 Copyright (c) 2010 IETF Trust and 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
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.

Table of Contents

 1. Introduction ....................................................3
 2. Conventions Used in This Document ...............................4
 3. Benefits of Proxy Mobile IPv4 ...................................6
 4. Overview of Proxy Mobile IPv4 ...................................7
    4.1. Mobility Signaling for Mobile Device .......................7
         4.1.1. Proxy Registration during Initial Network
                Attachment ..........................................8
         4.1.2. Proxy Registration Renewal .........................11
         4.1.3. Proxy Handover Support .............................12
         4.1.4. Resource Cleanup ...................................13
    4.2. Establishment of a Bi-Directional Tunnel ..................14
         4.2.1. Packet Forwarding ..................................14
         4.2.2. Broadcast and Multicast ............................14
         4.2.3. Forwarding between Devices on the Same PMA .........15
    4.3. Security Association between the PMA and the HA ...........15
    4.4. Registration Sequencing ...................................15
    4.5. Mobile Device Interface Configuration .....................16
    4.6. Dynamic HA Discovery ......................................16
 5. Proxy Mobile IPv4 Extensions ...................................16
    5.1. PMIPv4 Per-Node Authentication Method Extension ...........17
    5.2. Proxy Mobile IPv4 Interface ID Extension ..................18
    5.3. Proxy Mobile IPv4 Device ID Extension .....................18
    5.4. Proxy Mobile IPv4 Subscriber ID Extension .................19
    5.5. PMIPv4 Access Technology Type Extension ...................20
 6. Appearance of Being at Home Network ............................22
    6.1. ARP Considerations ........................................22
    6.2. ICMP Considerations .......................................23
    6.3. DHCP Considerations .......................................23
    6.4. PPP IPCP Considerations ...................................24
    6.5. Link-Local Multicast and Broadcast Considerations .........24
 7. Proxy Mobility Agent Operation .................................24
 8. Home Agent Operation ...........................................25
    8.1. Processing Proxy Registration Requests ....................26

Leung, et al. Informational [Page 2] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

 9. Mobile Device Operation ........................................26
    9.1. Initial Network Access ....................................27
    9.2. Mobile Device Mobility ....................................27
    9.3. Sending and Receiving Packets .............................27
 10. Proxy Mobile IPv4 Use Case in WiMAX ...........................28
    10.1. Proxy Mobile IPv4 Call Flow Examples with Split
          PMA in WiMAX .............................................31
 11. Proxy Mobile IPv4 Use Case in 3GPP2 ...........................33
    11.1. Handover Considerations in 3GPP2 .........................36
 12. IANA Considerations ...........................................37
    12.1. Mobile IPv4 Extension Types ..............................38
    12.2. Mobile IPv4 Error Codes ..................................38
 13. Security Considerations .......................................38
 14. Acknowledgements ..............................................38
 15. References ....................................................39
    15.1. Normative References .....................................39
    15.2. Informative References ...................................39

1. Introduction

 There are many IPv4 devices 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
 that perform the 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 (PMA)) to
 inform the network entity on the home network (referred to as the
 Home 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 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., 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

Leung, et al. Informational [Page 3] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

 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 in 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; all other general 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 signaling for
    achieving mobility for an obtained IP address.
 Proxy Mobile IPv4 Client (PMIPv4 Client)
    This network function is responsible for initiating and
    maintaining the Proxy Mobile IPv4 registration on behalf of the
    mobile device.  Essentially, it performs the Mobile IPv4 client
    function but is hosted in the network.  In some cases, this
    function is collocated with the Foreign Agent; in others, it is
    not.  In both cases, Proxy Mobile IPv4 registration still goes via
    the Foreign Agent at all practical 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 reachability state.  The additional

Leung, et al. Informational [Page 4] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

    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 PMIPv4 client.  It serves the purpose of tunnel
    endpoint from Proxy Mobile IPv4 perspective.
 Access Router (AR)
    Access Router is a commonly used term that refers to the node in
    the network 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 PMIPv4 client and the FA functions.  The
    PMIPv4 client and the FA collocation in the Access Router
    constitute an integrated PMA.  When the PMIPv4 client and the FA
    functions are not collocated in the Access Router, it is referred
    to as a split PMA.  A 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.

Leung, et al. Informational [Page 5] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

3. Benefits of Proxy Mobile IPv4

 Proxy Mobile IPv4 (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: Mobile IPv4.
 Implementations of Mobile IPv4 can be re-used (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 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 of Existing Home Agent
     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, and sharing the same
     protocol is a significant benefit.
 3.  Reduction of 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, mobility protocol, it can be used for any type of
     access network.
     From the network perspective, a mobile device is identified by
     the 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

Leung, et al. Informational [Page 6] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

     multiple networks concurrently, although the network treats each
     access interface independently.  This feature can be supported
     with the use of the PMIPv4 Access Technology Type Extension
     (Section 5.5).
 5.  Support for IPv4 and IPv6 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 [RFC5454].  There are additional
     enhancements needed, which are described in "Proxy Mobile IPv6"
     [RFC5213].  However, support for an IPv6 host is out of 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 authentication, the
 PMA exchanges Proxy Mobile IPv4 registration messages with the HA to
 set up proper routing and tunneling of packets from/to the Mobile
 Node.  The PMIPv4 client is responsible for initiating the Proxy
 Mobile IPv4 registration.  For integrated PMA, the PMIPv4 client and
 the FA interaction is all within the node.  In the case of split PMA
 implementation, the interactions between the 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 [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
 that interact with Proxy Mobile IP are identified and explained in
 more detail.  The PPP/IPCP (IP Control Protocol) protocol involves a
 PPP client in the mobile device and a Network Access Server (NAS) in
 the AR.  DHCP involves a DHCP client in the MN and a DHCP server in
 either the AR or the HA.  PMIPv4 involves a PMA in the AR and an HA
 in the router on the home network.  The Authentication,
 Authorization, and Accounting (AAA) protocol involves a AAA client in
 the AR and a AAA server in the network.  The 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 document.

Leung, et al. Informational [Page 7] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

4.1.1. Proxy Registration during Initial Network Attachment

              +----+        +-------+      +-------+      +-----+
              |    |        | AR /  |      |       |      |     |
              | MN |        | PMA   |      |  AAA  |      |  HA |
              |    |        |       |      |       |      |     |
              +----+        +-------+      +-------+      +-----+
                 |               |             |             |
                 |     1a        |     1b      |             |
 Authentication  |<------------->|<----------->|             |
                 |               |             |             |
                 |     2         |             |             |
            +->  |-------------->|             |             |
            |    |               |       3     |             |
            |    |               |-------------------------->| <-+
 Address    |    |               |             |             |   |PMIP
 Acquisition|    |               |       4     |             |   |
            |    |               |<--------------------------| <-+
            |    |     5         |             |             |
            +->  |<--------------|             |             |
                 |               |             |             |
                 |     6         |             |             |
 Data Forwarding |<------------->|<=========================>|
                 |               |             |             |
                  Figure 1: Network Connection Setup
 The initial network-attachment procedure is described below.  There
 are three distinct phases.  First, authentication and authorization
 happen when the mobile device accesses the network.  Then, the mobile
 device attempts to obtain an IP address.  This triggers Proxy Mobile
 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 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 either the
      Challenge Handshake Authentication Protocol (CHAP) [RFC1994] if
      PPP [RFC1661] is used or the Extensible Authentication Protocol
      (EAP) [RFC3748] over foo (foo being the specific access
      technology, or PANA [RFC4058]).  The AR acts as the NAS (Network
      Access Server) in this step.

Leung, et al. Informational [Page 8] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

 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., the
      user's profile, handset type, assigned Home Agent address, and
      other capabilities of the mobile device).
 2.   The mobile device requests an IP address via 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 has
      completed.
 3.   Triggered by step 2, the PMA sends 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 (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) 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 sets up the mobility binding entry for the mobile
      device after assigning an IP address or authorizing the
      requested Home Address.  The Home Agent may also assign a
      Generic Routing Encapsulation (GRE) key in this step (if GRE
      tunneling is used between the PMA and HA).  The HA returns the
      Home Address and the GRE key (if applicable) in the Proxy
      Registration Reply (PRRP) to the PMA.  If the requested Home
      Address is not authorized, the 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].
      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, which includes the PMIPv4-assigned Home Address

Leung, et al. Informational [Page 9] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

      in the 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 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 as the DNS server
      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 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 PMIPv4 signaling and
      DHCP exchanges, the interaction between 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 as DNS 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.

Leung, et al. Informational [Page 10] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

4.1.2. Proxy Registration Renewal

                  +----+        +-------+                  +-----+
                  |    |        | AR /  |                  |     |
                  | MN |        | PMA   |                  |  HA |
                  |    |        |       |                  |     |
                  +----+        +-------+                  +-----+
                     |               |                        |
                     |               |       1                |
                     |               |----------------------->|
   PMIPv4            |               |                        |
   Renewal           |               |       2                |
                     |               |<-----------------------|
                     |               |                        |
                     |               |                        |
               Figure 2: Network Connection Maintenance
 The 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 exchanges
 between the AR and HA.
 1.  Before the PMIPv4 registration lifetime 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.
     This PRRQ is similar to the initial PRRQ (i.e., HA field set to
     the assigned 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.

Leung, et al. Informational [Page 11] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

4.1.3. Proxy Handover Support

                  +----+        +-------+      +-------+      +-----+
                  |    |        | New   |      |  Old  |      |     |
                  | MN |        | AR /  |      |  AR / |      |  HA |
                  |    |        | PMA   |      |  PMA  |      |     |
                  +----+        +-------+      +-------+      +-----+
                     |               |             |             |
                     |     1         |             |             |
   Authentication    |<------------->|             |             |
                     |               |             |             |
                     |               |       2     |             |
                +->  |               |-------------------------->|
   PMIPv4       |    |               |             |             |
                |    |               |       3     |             |
                +->  |               |<--------------------------|
                     |               |             |             |
                     |     4         |             |             |
   Data Forwarding   |<------------->|<=========================>|
                     |               |             |             |
                         Figure 3: AR Handover
 The AR handover procedure is described below.  There are three
 phases.  First, authentication and authorization 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, using the security method for network re-attachment.
 2.  Triggered by successful authentication, the PMA sends a PRRQ to
     the HA.  The HA's IP address is typically obtained or is known by
     the method used for fast re-authentication during AR handover
     (e.g., context transfer between the two 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 updates the existing mobility binding entry for
     the mobile device upon processing the PRRQ.  The 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

Leung, et al. Informational [Page 12] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

     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 Sections
     6.1, 6.2, and 6.3 of this document for 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 PMIPv4
 and other associated states for 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.  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., specifically to the Foreign Agent entity) in
     order to clean up unused resources in an expeditious manner.

Leung, et al. Informational [Page 13] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

 2.  The old PMA removes the 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 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 2 information such as the source 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 to the tunnel associated with each
 mobile device, based on the source MAC address.
 The PMA de-encapsulates any packets received on the tunnel from the
 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).  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 to the link associated with each mobile device,
 based on the GRE 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 (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

Leung, et al. Informational [Page 14] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

 process them in accordance to [RFC3344], [RFC3024], and [MIP4MCBC].
 Only the Direct Encapsulation Delivery Style is supported, as there
 is no encapsulation for the packets between the mobile device and
 PMA.

4.2.3. Forwarding between Devices on 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 should be routed via the HA without taking a local
 shortcut on the PMA.  This ensures that data-traffic enforcement at
 the HA is not bypassed.

4.3. Security Association 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.,
 same security association for all mobile devices) or per MN (i.e.,
 unique security association per mobile device).  The method of
 obtaining the security association is outside the scope of this
 document.
 For per-node SA support, the FA-HA Authentication extension or 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, Encapsulating Security
 Payload (ESP) [RFC4303] in transport mode with mandatory integrity
 protection should be used.  The IPsec endpoints are the IP addresses
 of the PMA and HA.
 For per-MN SA support, the MN-HA Authentication extension and/or MN-
 AAA Authentication 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.  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 this document.

Leung, et al. Informational [Page 15] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

 The method above is sufficient when there is a single source for
 signaling as in the split PMA case.  However, in the integrated PMA
 case, the Proxy Registration Request is sent from different sources
 (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.
 Note that, for the split PMA model as used in WiMAX Forum (see
 Section 10), the PMIPv4 client remains anchored during handover (see
 Section 10.1).  In this case, the PMIPv4 client is the only source of
 the PRRQ.  However, there are cases (such as PMIPv4 client relocation
 and uncontrolled handover 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, vendor-specific extensions (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 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., MN-HA or FA-HA Authentication extension) in the registration
 message.

Leung, et al. Informational [Page 16] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

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 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 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, 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 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) are allocated and managed by IANA.  The
       following values have been assigned to the specified method
       types.
       0: Reserved
       1: FA-HA Authentication
       2: IPsec Authentication

Leung, et al. Informational [Page 17] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

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

Leung, et al. Informational [Page 18] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

    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) are allocated and managed by IANA.  The
       following values have been assigned to the 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.

Leung, et al. Informational [Page 19] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

   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) are allocated and managed by IANA.  The
       following values have been assigned to the 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. PMIPv4 Access Technology Type Extension

 The Proxy Mobile IPv4 Access Technology Type extension indicates the
 type of 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

Leung, et al. Informational [Page 20] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

 multiple 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   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                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) are allocated and managed by IANA.  The
       following values have been assigned to the 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

Leung, et al. Informational [Page 21] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

       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 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., WLAN, WiMAX Ethernet
 Convergence Sublayer), the mobile device sends ARP requests for the
 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.

Leung, et al. Informational [Page 22] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

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

Leung, et al. Informational [Page 23] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

    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, DHCP 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 accesses the network via PPP [RFC1661], LCP
 (Link Control Protocol) CHAP is used to authenticate the user.  After
 authentication, the NAS (which is the AR/PMA) sends the Proxy Mobile
 IPv4 Registration Request to the HA.  The HA responds with the Home
 Address in the 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 that are in the same subnet and 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, with the exceptions identified below.
  1. No agent discovery (i.e., agent solicitation and advertisement) is

supported.

  1. The D-bit (De-encapsulation by MN) in the Registration Request is

always set to zero.

Leung, et al. Informational [Page 24] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

 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, at a minimum, for
 sending a proxy registration:
 1.  NAI of the mobile device.
 2.  MN-HA security association, when per-mobile device security
     association is used.
 3.  FA-HA Mobility security association or IPsec security association
     when per-node security association is used.  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.
 This information is typically downloaded from the AAA server during
 access authentication.

8. Home Agent Operation

 The Home Agent has the functionality 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 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 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 PMIPv4 service for the mobile device at the PMA by
     contacting the AAA server.

Leung, et al. Informational [Page 25] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

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

8.1. Processing Proxy Registration Requests

 When 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 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 cannot process the Proxy Mobile IPv4 Extensions
 defined in this document, it sends a Registration Reply with error
 code PMIP_UNSUPPORTED ("Proxy Registration not supported by the HA").
 In the case when the PMA is not allowed to send a Proxy Registration
 Request to the HA, the HA sends a Proxy Registration Reply with error
 code PMIP_DISALLOWED ("Proxy Registrations from this PMA are not
 allowed").
 A PMA receiving these error codes SHOULD NOT retry sending 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 [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 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.

Leung, et al. Informational [Page 26] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

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
 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 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, which is out of the
 scope of this document.
 Once the 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).

9.3. Sending and Receiving Packets

 All packets that are to be sent from the mobile device to the
 Corresponding Node (CN) will be sent as normal IPv4 packets, setting
 the Source Address of the IPv4 header to the Home Address and the
 Destination Address to the Corresponding Node's IP address.  In 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 by the
 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, 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.

Leung, et al. Informational [Page 27] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

 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:

Leung, et al. Informational [Page 28] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

                                          |
                                          |            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 for PMIPv4 Use
 As shown in the figure above, WiMAX NWG uses the split PMA model.
 The PMIPv4 client is collocated with the NAS in ASN1 (aka,
 Authenticator ASN).  The NWG architecture divides the network into
 two parts.  The Access part is termed the "Access Service Network"
 (ASN).  The Core part is termed the "Connectivity Service Network"
 (CSN).  The MN attaches to an 802.16 radio in the ASN2 (aka, Anchor
 Data Path Function).  The radio (base station) connects to the Anchor
 Data Path Function (A_DPF) in 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

Leung, et al. Informational [Page 29] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

 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] defines a key bootstrapping scheme
 for use with Proxy Mobile IPv4.  The specification uses per-MN
 security association for Proxy Mobile IPv4 operation.  The relevant
 keys (e.g., MN-HA key) are derived using EAP authentication as
 specified in this document.  For more information, please refer to
 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.  It is provided with
 FA-HA AE.  The FA-HA key is also bootstrapped via the same key
 hierarchy that is described in Section 4.3 of [NWG].
 The Proxy Mobile IPv4 operation in WiMAX NWG is aligned with the
 basic Proxy Mobile IPv4 operation as described in Section 4 of this
 document.  There are specific considerations for WiMAX NWG 1.0.0 use
 of Proxy Mobile IPv4.  These are listed below:
 1.  Use of per-MS SA for Proxy Mobile IPv4 registration.  In this
     case, MN-HA AE is used.
 2.  Use of split PMA to handle FA relocation while the PMIPv4 client
     remains anchored with the NAS (Authenticator ASN).
 3.  Only the Proxy Mobile IPv4 Access Technology Type 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 PMIPv4 client and the FA interact via the WiMAX specific
     reference point and protocol (aka, R4).  For more information,
     please refer to the NWG specification [NWG].
 6.  In order to handle inter-ASN (inter Access Router) 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, proxy) functions
     in the ASN are required to be configured with the same IP
     address.
 7.  The MN - AR (trigger for Proxy Mobile IPv4) interaction is based
     on DHCP.  DHCPDISCOVER from the MN triggers the Proxy Mobile IPv4
     process in the ASN.

Leung, et al. Informational [Page 30] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

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

 Since WiMAX uses the split PMA model, the call flows involve WiMAX
 proprietary signaling between the PMIPv4 client and FA within the
 PMA.  The following call flows illustrate this.
                   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 6: Proxy Handover Operation in WiMAX with Split PMA

Leung, et al. Informational [Page 31] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

 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 PMIPv4 client over 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), which connects to a new FA (aka, new Data Path Function
     in WiMAX).  Note that, in this case, the MN does not perform
     authentication and authorization.  The PMIPv4 tunnel remains
     between the old FA (aka, old Data Path Function in WiMAX).  The
     data flows through the PMIPv4 tunnel between the HA and the old
     FA, and through the 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 a WiMAX-specific R4
     reference point to initiate the handover process.
 3.  The new FA uses the WiMAX-specific R4 reference point to request
     the PMIPv4 client to begin the PMIPv4 handover.
 4.  Triggered by step 3, the PMIPv4 client sends 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.  The PRRQ is embedded in the WiMAX-specific R4
     packet.
 5.  The new FA forwards the PRRQ to the HA.
 6.  The Home Agent updates the existing mobility binding entry for
     the mobile device upon processing the PRRQ.  The Home Agent
     responds back to the new FA with PRRP.
 7.  The new FA forwards the PRRP after encapsulating it in a WiMAX-
     specific R4 packet to the PMIPv4 client.
 8.  The new FA and the old FA exchange WiMAX-specific R4 messages
     between them to confirm the handover.  The old FA cleans up 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.

Leung, et al. Informational [Page 32] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

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 (BS) and access gateway (AGW)
 2.  Mobility between the AGW and the Home Agent (HA).
 As shown in the diagrams below, in use case 1, the BS acts as the PMA
 and the AGW acts as the HA for Proxy Mobile IPv4 operation.  In use
 case 2, the AGW acts as the PMA while the HA assumes the role of the
 Home Agent.
                   RAN                            Core
                +-------+                       +------+
    +----+      | BS/   |             PMIPv4    |      |
    | MN |------| PMA   |-----------------------| AGW/ |
    +----+      |       |                       |  HA  |
                |       |                       +------+
                +-------+
              Integrated PMA
    Figure 7: 3GPP2's PMIPv4 Use Case 1 - BS-AGW Interface Mobility
                   RAN                            Core
                +-------+                       +------+
    +----+      | AGW/  |             PMIPv4    |      |
    | MN |------| PMA   |-----------------------|  HA  |
    +----+      |       |                       |      |
                |       |                       +------+
                +-------+
              Integrated PMA
    Figure 8: 3GPP2's PMIPv4 Use Case 2 - AGW-HA Interface Mobility
 The figure below shows a simplified 3GPP2 architecture.  For details,
 please refer to the 3GPP2 Converged Access Network (CAN) architecture
 ([3GPP2]).

Leung, et al. Informational [Page 33] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

                         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 layer 2 establishment with the BS/PMA and performs
      access authentication/authorization.  During this phase, the MN
      runs EAP over Ultra Mobile Broadband (UMB).  The BS acts as the
      NAS in this phase.

Leung, et al. Informational [Page 34] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

 1b.  The BS exchanges AAA messages with the 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., user's profile, handset type, assigned Home Agent
      address, and other capabilities of the MN).  This information is
      passed to the PMA/BS (as necessary) to set up the PMIPv4 tunnel
      in the next step(s).
 2.   The MN sends layer 2 signaling messages to the BS/PMA to trigger
      the PMIPv4 tunnel setup process.
 3.   Triggered by step 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, 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, the same procedures are followed except the PMIPv4
 tunnel is established between the AGW and the HA.  In this case, GRE
 tunneling may not be used.

Leung, et al. Informational [Page 35] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

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

Leung, et al. Informational [Page 36] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

 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 registers 47 for the Proxy Mobile IPv4
 Non-Skippable Extension and 147 for Proxy Mobile IPv4 Skippable
 Extension, both of which are described in Section 5.  The ranges for
 Mobile IPv4 [RFC3344] extension types are defined at
 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 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 defined in
 Section 5.1 of this document, introduces a new authentication method
 numbering space, where the values from 0 to 2 have been assigned per
 this document.  Approval of new Access Technology type values are to
 be made through IANA Expert Review.
 The PMIPv4 Device ID 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 assigned per this document.  Approval of new
 Access Technology type values are to be made through IANA Expert
 Review.
 The PMIPv4 Subscriber ID 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 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.

Leung, et al. Informational [Page 37] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

12.1. Mobile IPv4 Extension Types

 This document introduces the following Mobile IP extension types.
 Name       : Proxy Mobile IPv4 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 described in RFC 3344 [RFC3344] or IPsec [RFC4301].  Each
 PMA needs to have an security association (e.g., MN-HA, FA-HA, IPsec
 AH/ESP) with the HA to register the MN's IP address.  The security
 association can be provisioned by the 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).

Leung, et al. Informational [Page 38] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

15. References

15.1. Normative References

 [3GPP2]      "3GPP2 Basic IP Service for Converged Access Network",
              X.S0054-100-0 Version 2.0, August 2008.
 [NWG]        "WiMAX Forum Network Architecture (Stage 3: Detailed
              Protocols and Procedures)" Release 1, Version 1.2.3,
              July 2008.
 [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.
 [RFC3024]    Montenegro, G., Ed., "Reverse Tunneling for Mobile IP,
              revised", RFC 3024, January 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., "The PPP Internet Protocol Control
              Protocol (IPCP)", RFC 1332, May 1992.
 [RFC1661]    Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
              STD 51, RFC 1661, July 1994.

Leung, et al. Informational [Page 39] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

 [RFC1994]    Simpson, W., "PPP Challenge Handshake Authentication
              Protocol (CHAP)", RFC 1994, August 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., "Ethernet Address Resolution 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.

Leung, et al. Informational [Page 40] RFC 5563 WiMAX Forum / 3GPP2 PMIPv4 February 2010

Authors' Addresses

 Kent Leung
 Cisco Systems
 170 West Tasman Drive
 San Jose, CA  95134
 US
 EMail: kleung@cisco.com
 Gopal Dommety
 Cisco Systems
 170 West Tasman Drive
 San Jose, CA  95134
 US
 EMail: gdommety@cisco.com
 Parviz Yegani
 Juniper Networks
 1194 North Mathilda Ave.
 Sunnyvale, CA 94089-1206
 EMail: pyegani@juniper.net
 Kuntal Chowdhury
 Starent Networks
 30 International Place
 Tewksbury, MA  01876
 USA
 EMail: kchowdhury@starentnetworks.com

Leung, et al. Informational [Page 41]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5563.txt · Last modified: 2010/02/09 02:50 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki