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

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 5563

MIP4                                                            K. Leung
Internet-Draft                                                G. Dommety
Intended status: Informational                                 P. Yegani
Expires: March 23, 2008                                    Cisco Systems
                                                            K. Chowdhury
                                                        Starent Networks
                                                      September 20, 2007


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

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on March 23, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   Mobile IPv4 is a standard mobility protocol that enables 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


Leung, et al.            Expires March 23, 2008                 [Page 1]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


   having the Mobile IPv4 client function in a network element to
   provide mobility support for an unaltered and mobility-unaware IPv4
   device, and the existing application of PMIPv4 in WiMAX Forum and
   3GPP2.















































Leung, et al.            Expires March 23, 2008                 [Page 2]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   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 . . . . . . . . . . . . . . 10
       4.1.3.  Proxy Handover Support . . . . . . . . . . . . . . . . 11
       4.1.4.  Resource Cleanup . . . . . . . . . . . . . . . . . . . 13
     4.2.  Establishment of Bi-Directional Tunnel . . . . . . . . . . 13
       4.2.1.  Packet Forwarding  . . . . . . . . . . . . . . . . . . 13
       4.2.2.  Forwarding Between Devices on same PMA . . . . . . . . 14
     4.3.  Security Association Between the PMA and the HA  . . . . . 14
     4.4.  Registration Sequencing  . . . . . . . . . . . . . . . . . 15
     4.5.  Mobile Device Interface Configuration  . . . . . . . . . . 15
     4.6.  Dynamic HA Discovery . . . . . . . . . . . . . . . . . . . 15
   5.  Proxy Mobile IPv4 Extensions . . . . . . . . . . . . . . . . . 15
     5.1.  PMIPv4 Per-Node Authentication Method Extension  . . . . . 15
     5.2.  Proxy Mobile IPv4 Device ID Extension  . . . . . . . . . . 16
   6.  PMIP Access Network Type Extension . . . . . . . . . . . . . . 17
   7.  PMIP Heartbeat Extension . . . . . . . . . . . . . . . . . . . 18
   8.  Appearance of Being at Home Network  . . . . . . . . . . . . . 19
     8.1.  ARP Considerations . . . . . . . . . . . . . . . . . . . . 20
     8.2.  ICMP Considerations  . . . . . . . . . . . . . . . . . . . 20
     8.3.  DHCP Considerations  . . . . . . . . . . . . . . . . . . . 20
     8.4.  PPP IPCP Considerations  . . . . . . . . . . . . . . . . . 21
     8.5.  Link-Local Multicast and Broadcast Considerations  . . . . 22
   9.  Proxy Mobility Agent Operation . . . . . . . . . . . . . . . . 22
   10. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 23
     10.1. Processing Proxy Registration Requests . . . . . . . . . . 23
   11. Mobile Device Operation  . . . . . . . . . . . . . . . . . . . 24
     11.1. Initial Network Access . . . . . . . . . . . . . . . . . . 24
     11.2. Mobile Device Mobility . . . . . . . . . . . . . . . . . . 24
     11.3. Sending and Receiving Packet . . . . . . . . . . . . . . . 25
   12. Proxy Mobile IPv4 Use Case in WiMAX  . . . . . . . . . . . . . 25
   13. Proxy Mobile IPv4 Use Case in 3GPP2  . . . . . . . . . . . . . 28
     13.1. HO considerations in 3GPP2 . . . . . . . . . . . . . . . . 31
   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 32
     14.1. Mobile IPv4 Extension Type . . . . . . . . . . . . . . . . 32
     14.2. Mobile IPv4 Error Codes  . . . . . . . . . . . . . . . . . 33
   15. Security Considerations  . . . . . . . . . . . . . . . . . . . 33
   16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
   17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
   Intellectual Property and Copyright Statements . . . . . . . . . . 37



Leung, et al.            Expires March 23, 2008                 [Page 3]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


1.  Introduction

   There are many IPv4 devices which do not have or cannot be enabled
   with Mobile IPv4 [1] functionality.  Yet, mobility for them is
   essential.  Proxy Mobile IPv4 provides mobility support without
   "touching" these devices.  The scheme is based on network elements
   which 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 as the Proxy Mobility Agent) to inform the
   network element on the home network (referred as the Home Agent)
   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 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 elements 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
   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 elements, 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 12) and 3GPP2 (Section 13).



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

      The following new terminology and abbreviations are introduced in
      this document and all other general mobility related terms as



Leung, et al.            Expires March 23, 2008                 [Page 4]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


      defined in Mobile IPv4 specification [1].

      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 (PMIP 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 it is hosted in the network.  In some cases, this
         function is collocated with the Foreign Agent and 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 [1] 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 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 [1] is used in the Proxy
         Mobile IPv4 scheme.  It is either collocated with or separate
         from the PMIP Client.  It serves the purpose of tunnel end-
         point from Proxy Mobile IPv4 perspective.

      Access Router (AR)

         Access Router is a commonly used term that refers to the node
         in the network which 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 and the FA functions.  The
         PMIP Client and the FA collocation in the Access Router
         constitute an integrated PMA.  When the PMIP Client and the FA
         functions are not collocated in the Access Router, it is



Leung, et al.            Expires March 23, 2008                 [Page 5]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


         referred as a split PMA.

      Proxy Registration Request (PRRQ)

         The Registration Request message sent by the Proxy Mobility
         Agent to the Home Agent to set up a mobility binding entry for
         a mobile device.  The message format is identical to that of
         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 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 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) is designed to satisfy the requirements
   listed below.  In addition, the solution leverages well-studied
   specification and highly available implementations.  The 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, ones that have or others that lack 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 running on a myriad of operating systems
          and networking stacks.





Leung, et al.            Expires March 23, 2008                 [Page 6]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


   2.  Re-use of Existing Home Agent

          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 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, but the network can prioritize which
          path to use for the mobile device.  This feature can be
          supported with the use of the PMIP Access Network Type
          Extension (Section 6).

   5.  Support for IPv4 and IPv6 Host

          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 [3] and [4].  The former draft
          covers the interface between MN and AR whereas the latter
          draft specifies the extensions for IPv6 address in the PMIP
          signaling enhancements between the AR and the HA.



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 PMIP Client is responsible for initiating the proxy Mobile
   IPv4 registration.  For integrated PMA, the PMIP Client and the FA
   interaction is all within the node.  In the case of split PMA



Leung, et al.            Expires March 23, 2008                 [Page 7]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


   implementation, the interaction between the PMIP Client and the FA
   are exposed.  The interface between the PMIP Client and the FA in the
   split PMA scenario is the same as the one defined in RFC3344 and
   consequently out of 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 interact with Proxy Mobile IP are identified and explained in
   more details.  PPP/IPCP protocol involves PPP client in the mobile
   device and NAS in the AR.  DHCP protocol involves a DHCP Client in
   the MN and DHCP Server in either the AR or the HA.  PMIP protocol
   involves a PMA in the AR and an HA in the router on the home network.
   AAA protocol involves a AAA Client in the AR and a AAA Server in the
   network.  The colocation of the functional entities in the AR/HA
   enables parameters to be shared/processed among the protocols.

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






Leung, et al.            Expires March 23, 2008                 [Page 8]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


   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 mobile
   device attempts to obtain an IP address.  This triggers Proxy Mobile
   IP which assigns the IP address and sets up forwarding between the
   PMA and HA.  The host configuration parameters may be passed in the
   PMIP signaling.  Finally, mobile device configures its IP stack with
   the IP address and obtained host configuration.  Packets to and from
   the mobile device transit both the PMA and HA.

   1a.  The mobile device establishes L2 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
   [5] or PAP [6] if PPP [7] is used or EAP [8] over foo (foo being the
   specific access technology or PANA [9]).  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. user's profile,
   handset type, assigned home agent address, and other capabilities of
   the mobile device).

   2.  The mobile device requests for an IP address via an PPP/IPCP [10]
   or DHCP [11].  Specifically for PPP, the PPP client sends 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 holds the DHCP
   Discover message until PMIPv4 signaling completes.

   3.  Triggered by step 2, the PMA sends an 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 FA in this
   case).  The Home Address field is set to zero or the IP address
   specified as hint in the DHCP or IPCP message.  The PRRQ MUST be
   protected by the methods described in Security Considerations
   (Section 15).  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 returns the Home Address in the Proxy
   Registration Request (PRRP) to the PMA.  After the PMA processes the
   PRRP, the forwarding path for the Home Address between the PMA and HA
   is established.  The event completes the Proxy Mobile IPv4 signaling



Leung, et al.            Expires March 23, 2008                 [Page 9]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


   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 IPCP Configure-Nak
   which includes the PMIP assigned Home Address in the IP-Address
   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 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. 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
   tunneled to the DHCP server on the HA.  The DHCP server sends a DHCP
   Offer with the PMIP assigned Home Address in the yiaddr field to the
   DHCP relay agent, which forwards 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.

   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.

4.1.2.  Proxy Registration Renewal


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



Leung, et al.            Expires March 23, 2008                [Page 10]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


                 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 exchange between
   the AR and HA.

   1.  Before the PMIP registration lifetime expires and the AR has not
   receive any indication that the mobile device detached from the
   network, the PMA sends PRRQ to the HA to extend the duration of the
   mobility binding of the mobile device.  The PRRQ is similar as 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.

4.1.3.  Proxy Handover Support


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


                           Figure 3: AR Handover




Leung, et al.            Expires March 23, 2008                [Page 11]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


   The AR handover procedure is described below.  There are three
   phases.  First, authentication and authorization happens when 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 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 an PRRQ to
   the HA.  The HA's IP address is obtained or known typically by the
   method used for fast reauthentication 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 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 Section 8.1, ICMP
   Section 8.2 and DHCP Section 8.3 considerations for details.  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.
















Leung, et al.            Expires March 23, 2008                [Page 12]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


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 is necessary when the old AR needs to delete its PMIP and other
   associated states for the 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 is out of 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 [12]) to the old
   PMA in order to clean up unused resources in an expeditious manner.

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

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

4.2.  Establishment of Bi-Directional Tunnel

   The PMA and HA set up a tunnel between them for the Home Address
   after the PMIP 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



Leung, et al.            Expires March 23, 2008                [Page 13]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


   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 takes into account the Layer 2 information such as the
   source MAC address or ingress interface.  This allows overlapping IP
   addresses to be supported for the packet from the mobile device.

   Any packets received on the tunnel from HA, the PMA de-encapsulates
   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 GRE Key).  This allows overlapping IP
   addresses to be supported for the packet destined to the mobile
   device.

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

4.2.2.  Forwarding Between Devices on 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 still routed via the HA without taking local
   shortcut on the PMA.

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 of scope of this
   document.

   For per node SA support, FA-HA Authentication Extension or IPSec is
   used to authenticate the signaling.  This method is used also in
   Registration Revocation [12].  Use of IPSec Encapsulating Security
   Payload (ESP) is optional.  This method is indicated by the Proxy
   Mobile IPv4 Extension in the message.

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





Leung, et al.            Expires March 23, 2008                [Page 14]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


4.4.  Registration Sequencing

   Since the proxy registration request is sent from different sources
   (i.e. different PMAs), a method of determining the sequence of the
   messages is required on the HA.  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 Network Time Protocol [13] or
   some other method.  Note that the use of nonce for sequencing and
   replay protection is outside of scope.

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.  If
   the Home Agent's IP address is on the same subnet as the Home
   Address, then it is used as the default gateway.  Otherwise, the
   Configuration Option Exchange extensions [14] should be used to
   obtain the default gateway.  The DNS server addresses may also be
   obtained via the extensions.  Alternatively, the PMA can supply its
   known DNS server addresses to the mobile device.

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 Dynamic HA Assignment [15].


5.  Proxy Mobile IPv4 Extensions

   The following extensions provide Proxy Mobile IPv4 support by
   indicating the proper authentication and sequencing operation.

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



Leung, et al.            Expires March 23, 2008                [Page 15]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


   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

         Proxy Mobile IPv4 Extension (non-skippable value to be assigned
         by IANA)

      Sub-Type

         1 (PMIPv4 Per-Node Authentication Method)

      Length

         1

      Method

         1 (FA-HA Authentication)

         2 (IPSec Authentication)

5.2.  Proxy Mobile IPv4 Device ID Extension

   The Proxy Mobile IPv4 Device extension identifies the L2 address of
   the device.  For example, this is the MAC address and Mobile
   Equipment Identifier for the mobile device's interface that is
   attached on the an IEEE or cellular network, respectively.  The
   information MAY be included in the Registration Request when the PMA
   is aware of it.






Leung, et al.            Expires March 23, 2008                [Page 16]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


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



                        PMIPv4 Device ID Extension

      Type

         Proxy Mobile IPv4 Extension (non-skippable value to be assigned
         by IANA)

      Sub-Type

         2 (PMIPv4 Device ID)

      Length

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

      ID-Type

         1: Ethernet MAC address

         2: Mobile Equipment Identifier (MEID)

         3: Electronic Serial Number (ESN)

      Identifier

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


6.  PMIP Access Network Type Extension

   The Proxy Mobile IPv4 Access Network Type extension indicates the
   type of network (e.g.  WLAN, cdma2000 EvDO) that the mobile device is
   attached.  This extension SHOULD be included in the Registration
   Request when the PMA is aware of the information.  The HA does not
   include the extension in the associated Registration Reply.




Leung, et al.            Expires March 23, 2008                [Page 17]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


        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            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Net-Type    |
       +-+-+-+-+-+-+-+-+



                    PMIP Access Network Type Extension

      Type

         Mobile IPv4 Extension (non-skippable value to be assigned by
         IANA)

      Sub-Type

         3 (Access Network Type)

      Length

         1

      Net-Type

         1: 3GPP2 cdma2000 1xRTT

         2: 3GPP2 cdma2000 HRPD

         3: 3GPP2 UMB

         4: WiMAX

         5: WiFi

         6: 3GPP UTRAN

         7: 3GPP LTE


7.  PMIP Heartbeat Extension

   The Proxy Mobile IPv4 Heartbeat extension provides a mechanism for
   the PMA to detect the connectivity and liveliness of the HA.  This
   extension SHOULD be included in the Registration Request when the PMA
   wants to check the connectivity to the HA that can manage PMIP



Leung, et al.            Expires March 23, 2008                [Page 18]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


   registrations.  The HA includes the extension in the associated
   Registration Reply to acknowledge the heartbeat.  When the HA does
   not respond to the heartbeats, the PMA can assume that the HA is not
   reachable and can take recovery action on behalf of attached mobile
   devices.  The use of this extension requires per-node security
   association and not correlated to any mobile device (i.e. no NAI
   extension in the message).


        0               1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |   Sub-Type    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                         PMIP Heartbeat Extension

      Type

         Mobile IPv4 Extension (non-skippable value to be assigned by
         IANA)

      Length

         0

      Sub-Type

         4 (Heartbeat)


8.  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 elements emulate the
   home network to the mobile device attached on the network.  From the
   mobile device's perspective, it operates as it is at the home
   network.  However, the network is directing the mobile device's
   traffic to and from its current location and 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 ([16]), obtains an IP
   address and other host configuration via DHCP ([11]), and sends link-
   local multicast and broadcast packets.  The network's response to the
   host is equivalent to the situation when host is on the home network.
   When the link state changes, some hosts use ARP, ICMP, and/or DHCP to



Leung, et al.            Expires March 23, 2008                [Page 19]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


   detect if it has changed the point of attachment on the network.

8.1.  ARP Considerations

   For IEEE 802 type of access networks (e.g.  WLAN, WiMAX Ethernet
   Convergence Sublayer), the mobile device sends ARP request for the 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 for the packet to reach the CNs.

   A mobile device has ARP entries for 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.

8.2.  ICMP Considerations

   For movement detection, certain types of network stack on the mobile
   device will send an ICMP request [17] 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 should 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.

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

8.3.  DHCP Considerations

   DHCP [11] 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.



Leung, et al.            Expires March 23, 2008                [Page 20]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


   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 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 from the client are
   tunneled 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 [12] to
   the AR.

8.4.  PPP IPCP Considerations

   When the mobile device access the network via PPP [7], LCP 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 [10].  When mobile device moves to a new
   NAS, the same procedure happens and mobile device has the same IP
   address for communication.



Leung, et al.            Expires March 23, 2008                [Page 21]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


   The message exchange is illustrated in Figure 1.

8.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 are in the same subnet and send a duplicated
   packet to each of them.


9.  Proxy Mobility Agent Operation

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

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

      - D-bit (De-encapsulation by MN) in the Registration Request is
      always set to 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 12).

   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, these
       associations are specific only between PMA and HA, and
       cryptographically unrelated to the associations between the MN
       and other network nodes.

   4.  HA Address

   The information is typically downloaded from AAA server during access
   authentication.





Leung, et al.            Expires March 23, 2008                [Page 22]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


10.  Home Agent Operation

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

   1.  Sequencing between PRRQs from multiple PMAs.  There is a period
   after handover that may result in both the new PMA and old PMA
   sending PRRQs.  If the old PMA has not detected that the mobile
   device moved, it sends a PRRQ when re-registration timer expires.
   The timestamp and authentication are valid for the message.  The HA
   would process the PRRQ and set up forwarding to the old PMA.  This
   problem remains until the new PMA sends a re-registration message.

   The problem can be avoided by the use of Registration Revocation
   [12].  However, it can still happen when the revocation message does
   not reach the old PMA until after it had sent the PRRQ.  For example,
   the revocation message was dropped in transit.  In this case, the HA
   will send a revocation registration to the new PMA after setting up
   forwarding to the old PMA.  This should cause the new PMA to
   disconnect the mobile device, which needs to re-connect to the
   network.  The sequence of events should lead to the new PMA sending a
   PRRQ to the HA.  The problem is resolved eventually by revoking the
   PMIP states at the old PMA.  A method of maintaining sequence between
   PMA would be desirable.

   2.  Authentication of PRRQs based on per Node Security Association
   (FA-HA AE or IPsec AH/ESP).  The presence of MN-HA AE or MN-AAA AE in
   the PRRQ is not necessary in this case.  Since PMIP 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 service for the mobile device at the PMA by contacting
   the AAA server.

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

10.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 MBE, if
   present.  If the value in the message is zero or greater than or
   equal to the one in MBE, HA accepts the registration.  The HA replies
   with a sequence number that is one greater than larger value of
   either the MBE or Proxy Registration Request.  If the registration is
   denied, then HA sends error code "Administratively prohibited (65)".



Leung, et al.            Expires March 23, 2008                [Page 23]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


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




11.  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].  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 proper
   forwarding path for mobile device's traffic.

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


11.2.  Mobile Device Mobility

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



Leung, et al.            Expires March 23, 2008                [Page 24]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


   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 mobile device's
   information using a context transfer mechanism.

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


11.3.  Sending and Receiving Packet

   All packets that are 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 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.





12.  Proxy Mobile IPv4 Use Case in WiMAX

   WiMAX Forum Network Working Group (NWG) uses Proxy Mobile IPv4 scheme
   to provide IPv4 connectivity and IP mobility.  The relevant



Leung, et al.            Expires March 23, 2008                [Page 25]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


   specification from WiMAX Forum is [18].

   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 WiMAX Forum specification is
   illustrated in the following diagram:


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


               WiMAX NWG network configuration for PMIP use



   As shown in the figure above, WiMAX NWG uses the split PMA model.



Leung, et al.            Expires March 23, 2008                [Page 26]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


   The PMIP Client is collocated with the NAS (a.k.a.  Authenticator
   ASN).  The NWG architecture divides the network into two parts.  The
   Access part is termed as Access Service Network (ASN).  The Core part
   is termed as Core Service Network (CSN).  The MN attaches to a 802.16
   radio in the ASN. the radio (base station) connects to a ASN-GW (NAS)
   which then 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 the Access Router
   (ASN-GW).  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 more generic
   representation of the WiMAX NWG mobility framework.

   WiMAX NWG specification [18], defines key bootstrapping scheme for
   use with proxy Mobile IPv4.  The spec uses per MN security
   association for proxy Mobile IPv4 operation.  The relevant keys (e.g.
   MN-HA key) are derived using EAP keying framework.  For more
   information, please refer to section 4.3 of [18], 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 [18].

   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 PMIP Client
   remains anchored with the NAS (Authenticator ASN).

   3.  The Proxy Mobile IPv4 Extensions defined in this document are not
   used in NWG 1.0.0 specification.  These extensions may be used in
   future versions of the NWG specification.

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

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



Leung, et al.            Expires March 23, 2008                [Page 27]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


   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 is 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 proxy Mobile IPv4 process
   in the ASN.


13.  Proxy Mobile IPv4 Use Case in 3GPP2

   3GPP2 uses 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


           3GPP2's PMIP4 use case 1 - BS-AGW interface mobility










Leung, et al.            Expires March 23, 2008                [Page 28]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


                        RAN                            Core


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

                   Integrated PMA


           3GPP2's PMIP4 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
   ([19]).




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

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



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














Leung, et al.            Expires March 23, 2008                [Page 29]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


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



                   Network Connection Setup (use case 1)

   Description of the steps:

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

   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 setup the PMIP tunnel in the next step(s).

   2.  The MN sends layer 2 signaling messages to the BS/PMA to trigger
   the PMIP 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 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



Leung, et al.            Expires March 23, 2008                [Page 30]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


   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.

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



Leung, et al.            Expires March 23, 2008                [Page 31]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


        |               |              |          |




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


14.  IANA Considerations

   This specification reserves one number for the Proxy Mobile IPv4
   Extension in Section 5 from the space of numbers for non-skippable
   mobility extensions (i.e., 0-127) defined for Mobile IPv4 [1] at
   http://www.iana.org/assignments/mobileip-numbers.  This specification
   also creates a new subtype space for the type number of this
   extension.  The subtype values 1 and 2 are defined in this
   specification.  Similar to the procedures specified for Mobile IPv4
   number spaces, future allocations from this number space require
   expert review [20].

14.1.  Mobile IPv4 Extension Type

   This document introduces the following Mobile IP extension type.

   Name       : Proxy Mobile IPv4 Extension
   Type Value : TBD
   Section    :



Leung, et al.            Expires March 23, 2008                [Page 32]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


   Section 5

   Name       : Proxy Mobile IPv4 Extension
   Type Value : TBD
   Section    :

14.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         TBD
   Section 10.1

   Name                    Value    First referenced
   ----                    -----    ----------------
   PMIP_UNSUPPORTED         TBD
   Section 10.1

   Name                    Value    First referenced
   ----                    -----    ----------------
   PMIP_UNSUPPORTED         TBD



15.  Security Considerations

   The functionality in this document is protected by the Authentication
   Extensions described in RFC 3344 [1] or IPSec [21].  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.



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



Leung, et al.            Expires March 23, 2008                [Page 33]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


   Juan Huarte (Alcatel-Lucent), and Paula Tjandra (Motorola).


17.  References

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

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

   [3]   Navali, J. and K. Chowdhury, "IPv6 over Network based Mobile
         IPv4", draft-navali-ip6-over-netmip4-02.txt (work in progress),
         May 2007.

   [4]   Tsirtsis, G., "Dual Stack Mobile IPv4",
         draft-ietf-mip4-dsmipv4-03.txt (work in progress), August 2007.

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

   [6]   Lloyd, B. and W. Simpson, "PPP Authentication Protocols",
         RFC 1334, October 1992.

   [7]   Simpson, W., "The Point-to-Point Protocol (PPP) for the
         Transmission of Multi-protocol Datagrams over Point-to-Point
         Links", RFC 1331, May 1992.

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

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

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

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

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

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




Leung, et al.            Expires March 23, 2008                [Page 34]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


   [14]  Bharatia, J., "Mobile IPv4 Extension for Configuration Options
         Exchange", draft-ietf-mip4-gen-ext-04.txt (work in progress),
         July 2007.

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

   [16]  Plummer, D., "An Ethernet Address Resolution Protocol",
         RFC 826, November 1982.

   [17]  Postel, J., "Internet Control Message Protocol", RFC 792,
         September 1981.

   [18]  "WiMAX Forum Network Architecture, Release 1.0.0",  http://
         www.wimaxforum.org/technology/documents/
         WiMAXNetworkArchitectureStage2-3Rel1.0.0.zip, March 2007.

   [19]  "3GPP2 UMB CAN architecture",  ftp://ftp.3gpp2.org/TSGX/
         Projects/X.P0054%20Evolved%20Wireless%20IP%20Network/
         X.P0054-0%20v1.0/RF/.

   [20]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434,
         October 1998.

   [21]  Kent, S. and R. Atkinson, "Security Architecture for the
         Internet Protocol", RFC 2401, November 1998.

   [22]  Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network
         Address Translation (NAT) Devices", RFC 3519, May 2003.

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


Authors' Addresses

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

   Email: kleung@cisco.com







Leung, et al.            Expires March 23, 2008                [Page 35]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


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

   Email: gdommety@cisco.com


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

   Email: pyegani@cisco.com


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

   Email: kchowdhury@starentnetworks.com


























Leung, et al.            Expires March 23, 2008                [Page 36]

Internet-Draft          WiMAX Forum/3GPP2 PMIPv4          September 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

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

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


Intellectual Property

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

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

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


Acknowledgment

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





Leung, et al.            Expires March 23, 2008                [Page 37]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/