[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: Standards Track                               P. Yegani
Expires: January 4, 2008                                   Cisco Systems
                                                            K. Chowdhury
                                                        Starent Networks
                                                             Jul 3, 2007


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

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on January 4, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   Mobile IPv4 is a standard mobility protocol that enables IPv4 device
   to roam between networks.  The mobile device has the Mobile IP
   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 WiMAX
   Forum and 3GPP2 solution for the base Proxy Mobile IPv4 function


Leung, et al.            Expires January 4, 2008                [Page 1]

Internet-Draft              Proxy Mobile IPv4                   Jul 2007


   which enables another entity to provide mobility support on behalf of
   an unaltered and mobility-unaware IPv4 device.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  3
   3.  Solution Benefits  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Overview of Proxy Mobile IPv4  . . . . . . . . . . . . . . . .  6
     4.1.  Mobility Signaling for Mobile Node . . . . . . . . . . . .  6
       4.1.1.  Proxy Registration . . . . . . . . . . . . . . . . . .  6
       4.1.2.  Resource Cleanup . . . . . . . . . . . . . . . . . . .  8
     4.2.  Establishment of Bi-Directional Tunnel . . . . . . . . . .  9
     4.3.  Security Association Between MAG and LMA . . . . . . . . .  9
     4.4.  Registration Sequencing  . . . . . . . . . . . . . . . . . 10
   5.  Proxy Mobile IPv4 Extensions . . . . . . . . . . . . . . . . . 10
     5.1.  Proxy Mobile IPv4 Mode Extension . . . . . . . . . . . . . 10
     5.2.  PMIPv4 Per-Node Authentication Method Extension  . . . . . 11
   6.  Appearance of Being at Home Network  . . . . . . . . . . . . . 11
     6.1.  ARP Considerations . . . . . . . . . . . . . . . . . . . . 11
     6.2.  ICMP Considerations  . . . . . . . . . . . . . . . . . . . 12
     6.3.  DHCP Considerations  . . . . . . . . . . . . . . . . . . . 12
     6.4.  PPP IPCP Considerations  . . . . . . . . . . . . . . . . . 13
     6.5.  Link-Local Multicast and Broadcast Considerations  . . . . 13
   7.  Proxy Mobility Agent Operation . . . . . . . . . . . . . . . . 14
   8.  Local Mobility Agent Operation . . . . . . . . . . . . . . . . 14
     8.1.  Processing Proxy Registration Requests . . . . . . . . . . 14
   9.  Mobile Node Operation  . . . . . . . . . . . . . . . . . . . . 15
     9.1.  Initial Network Access . . . . . . . . . . . . . . . . . . 15
     9.2.  Moving to a New MAG  . . . . . . . . . . . . . . . . . . . 15
     9.3.  Packet forwarding  . . . . . . . . . . . . . . . . . . . . 16
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
     10.1. Mobile IPv4 Extension Type . . . . . . . . . . . . . . . . 16
     10.2. Mobile IPv4 Error Codes  . . . . . . . . . . . . . . . . . 17
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 20











Leung, et al.            Expires January 4, 2008                [Page 2]

Internet-Draft              Proxy Mobile IPv4                   Jul 2007


1.  Introduction

   There are many IPv4 devices which don't have or can't be enabled with
   Mobile IP [5] functionality.  For them, Proxy Mobile IPv4 provides
   mobility support without being "touched".  The scheme is based on an
   network node acting as a proxy Mobile Node that registers the
   location of the device and maintains reachability while the device is
   on the network.  The Foreign Agent and Home Agent perform their
   normal roles.  The following examples depict possible scenarios:

   1.  A Wireless LAN access point or cellular base station performs
       registration when a mobile station is associated on the airlink.

   2.  An access router or Foreign Agent performs registration when a
       Mobile Node is detected.

   3.  A wireless mobile termination device performs registration for an
       attached host.

   In the first two cases, the proxy node is a network element and the
   signaling can be considered part of the mobility management function
   of the domain.  The third case is when the proxy node moves along
   with the mobile device and may be considered as a part of the mobile
   device.  Some could argue that this is not a proxy mode of operation
   because the Mobile Node is the wireless mobile termination device.
   But the Home Address is "owned" by the host, meaning that packets to
   and from this IP address is received and sent by this host,
   respectively.  The wireless mobile termination device is providing
   mobility for this IP address unbeknownst to the host.  An example of
   this is cdma2000's Network Mode on the mobile termination unit.  For
   cdma2000, the true Mobile IP mode would be the Relay Mode, which is
   when the host operates as the Mobile Node.  Anyways, this mode of
   operation is well understood and commonly deployed.  The aim of this
   document is to describe how the network elements can provide mobility
   management for the mobile devices.



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

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




Leung, et al.            Expires January 4, 2008                [Page 3]

Internet-Draft              Proxy Mobile IPv4                   Jul 2007


      Mobility Node (MN)

         Throughout this document, the term mobile node is used to refer
         to an IPv4 node whose mobility is provided by the network.  The
         mobile node is not required to participate in any mobility
         related signaling for achieving mobility for an obtained IP
         address.  This document further uses explicit text when
         referring to a mobile node that is involved in mobility related
         signaling as per Mobile IPv4 specification [5].  The mobile
         node's capability or its involvement in any mobility related
         signaling for obtaining mobility for an address that is
         obtained outside the current proxy mobile IPv4 scheme is not
         relevant in the context of this document.

      Local Mobility Anchor (LMA)

         Local Mobility Anchor is the home agent for the mobile node in
         the Proxy Mobile IPv4 scheme.  It is the topological anchor
         point for the mobile node's home network and is the entity that
         manages the mobile node's reachability state.  It is important
         to understand that the LMA has the functional capabilities of a
         home agent as defined in Mobile IPv4 base specification [5] and
         with the additional required capabilities for supporting Proxy
         Mobile IPv4 as defined in this specification.

      Mobility Access Gateway (MAG)

         Mobility Access Gateway is a function that manages the mobility
         related signaling for a Mobile Node that is attached to its
         access link.  It is responsible for tracking the mobile node's
         attachment to the link and for signaling the mobile node's
         local mobility anchor.

      Proxy Registration Request (PRRQ)

         The message sent by the Mobility Access Gateway to the Mobile
         Node's Local Mobility Anchor to set up a mobility binding entry
         for the MN.

      Proxy Registration Reply (PRRP)

         The message sent by the Local Mobility Anchor in response to
         the proxy registration request received from the Mobility
         Access Gateway.







Leung, et al.            Expires January 4, 2008                [Page 4]

Internet-Draft              Proxy Mobile IPv4                   Jul 2007


3.  Solution Benefits

   Proxy Mobile IPv4 is designed to satisfy the requirements listed
   below.  In addition, the solution leverages well-studied
   specification and highly available implementations.  Only incremental
   enhancements are added to Mobile IPv4 protocol to enrich its breadth
   to support both client-based and network-based mobility.  For
   example, a Home Agent can anchor Mobile Nodes that have Mobile IP as
   well as the hosts without such capability.

   The network-based Mobility Management solution defined in this
   document provides the following benefits:

   1.  Support for Unmodified Hosts

          An overwhelming majority of IPv4 hosts do not have Mobile IP
          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.

   2.  Airlink Consumption

          Mobility-related signaling over the air-link is eliminated.
          Considering that Network Address Translation (NAT) is
          ubiquitous in IPv4 networks, a mobile node needs to send
          keepalives at short intervals to properly maintain the NAT
          states [6].  This can be performed by the MAG in the network
          which doesn't consume any air-link bandwidth.

   3.  Reduction of Signaling Overhead in the Network

          The MAG can aggregate multiple MNs on the same tunnel.  Thus
          the frequent keepalives needed to maintain the NAT states can
          be reduced significantly.  The signaling load on the network
          diminishes which increases the overall capacity.

   4.  Support for Heterogeneous Wireless Link Technologies

          One aspect is how to adopt the scheme to an access technology.
          Since Proxy Mobile IPv4 is based on a access technology
          independent mobility protocol, it can be used for any type of
          access network.

          The other aspect is how to support roaming across different
          access technologies.  As long as the MAG can use the same NAI
          to identify the MN for various access networks, roaming
          between them is possible.



Leung, et al.            Expires January 4, 2008                [Page 5]

Internet-Draft              Proxy Mobile IPv4                   Jul 2007


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



4.  Overview of Proxy Mobile IPv4

4.1.  Mobility Signaling for Mobile Node

   After network access authentication, MAG exchanges proxy registration
   messages with the LMA to set up proper routing and tunneling of
   packets from/to the Mobile Node.  As specified in RFC 3344 [5], a
   Foreign Agent may be used in the proxy registration procedure.
   However, for the remainder of this document, MAG is described to use
   direct registration to the LMA.  The difference is covered in RFC
   3344 [5] and can be presumed to be adaquately understood (e.g. the
   tunnel is between FA and HA instead of MAG and LMA/HA for FA
   registration and direct registration, respectively).

4.1.1.  Proxy Registration


      +----+        +-------+      +-------+   +-----+
      |    |        |       |      |       |   |     |
      | MN |        |  MAG  |      | AAA   |   | LMA |
      |    |        |       |      |       |   |     |
      +----+        +-------+      +-------+   +-----+
        |               |             |          |
        |     1a        |     1b      |          |
        |<------------->|<----------->|          |
        |               |             |          |
        |     2         |             |          |
        |-------------->|             |          |
        |               |       3     |          |
        |               |----------------------->|
        |               |             |          |
        |               |       4     |          |
        |               |<-----------------------|
        |     5         |             |          |
        |<--------------|             |          |
        |               |             |          |
        |     6         |             |          |
        |<------------->|<===========>|<========>|
        |               |             |          |




Leung, et al.            Expires January 4, 2008                [Page 6]

Internet-Draft              Proxy Mobile IPv4                   Jul 2007


                    Figure 1: Network Connection Setup



   Description of the steps:

   1a.  MN performs L2 establishment with the base station (not shown)
   and performs access authentication/authorization with the AR.  During
   this phase, the MN may run CHAP or PAP if PPP is used or EAP over foo
   (foo being the specific access technology or PANA).  The AR acts as
   the NAS in this phase.

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

   2.  The MN sends an IPCP config request to the AR in case of PPP to
   request for an IPv4 address.  If DHCP is uses, the DHCP client in the
   MN sends a DHCPDISCOVER message.  It is assumed in this document that
   the AR has a DHCP proxy/server function.

   3.  Triggered by step 2 the MAG in the AR sends an proxy registration
   request to the LMA.  The LMA's address is either received at step 1b
   from the Home AAA or it is discovered in an out of band way by the
   AR.  The PRRQ contains the Care-of Address (CoA) of the AR
   (collocated FA in this case).  The HoA field is set to ALL-ZERO-ONES-
   ADDRESS or the IP address specified as hint in DHCP or IPCP.  The
   PRRQ may be protected by the methods described in the Security
   Consideration section.  The derivation and distribution of the MN-HA
   or FA-HA key is outside the scope of this document.

   4.  The home agent registers the MN's session and assigns an HoA or
   authorizes the requested HoA.  The home agent returns the HoA in the
   PRRP.

   5.  The AR responds back to the MN with an IPCP config-NAK to suggest
   the IPv4 address which is the HoA from the LMA.  This happens in
   response to step 2.  If DHCP was used at step 2, the AR/DHCP-proxy/
   server sends back a DHCPOFFER with the IPv4 address set to the
   received HoA.

   6.  At this step, regular IPCP/NCP procedures get completed and the
   MN's IP stack is ready to receive or send IP packets.  If DHCP is
   used, the regular DHCPREQUEST and DHCPACK messages are exchanged and
   the MN's IP stack is configured with the assigned IPv4 address.




Leung, et al.            Expires January 4, 2008                [Page 7]

Internet-Draft              Proxy Mobile IPv4                   Jul 2007


4.1.2.  Resource Cleanup



        MN         New MAG     LMA      Previous MAG

        |           | Proxy     |           |
        |           | Reg       |           |
        |           | Request   |           |
      1)|           o---------->|           |
        |           |           |           |
        |           |           | Update    |
        |           |           | existing  |
      2)|           |           o MBE for MN|
        |           |           |           |
        |           |           | Reg       |
        |           |           | Revocation|
      3)|           |           o---------->|
        |           |           |           |
      4)|           |           |           o Remove visitor
        |           |           |           | entry for MN
        |           |           |           |
        |           |           |           | Reg
        |           |           |           | Revoc Ack
      5)|           |           |<----------o
        |           |           |           |
        |           | Proxy     |           |
        |           | Reg       |           |
        |           | Reply     |           |
      6)|           o<----------o           |


            Figure 2: Registration Revocation for Previous MAG



   MAG which no longer serves the Mobile Node needs to remove any
   associated mobility states and relinquish resources which are no
   longer needed.

   When the LMA receives a Proxy Registration Request for a Mobile Node
   with an existing Mobility Binding Entry (MBE), a Registration
   Revocation [3543] is sent to the previous MAG (in steps #1 through
   #3).  The previous MAG removes the visitor entry for the Mobile Node
   before sending acknowledgement to the LMA (in steps #4 and #5).  In
   parallel, the LMA sends the Proxy Registration Reply to the new MAG
   (in step #6).  At the end of sequence of events, only states for the
   MN are in the new MAG and the LMA.



Leung, et al.            Expires January 4, 2008                [Page 8]

Internet-Draft              Proxy Mobile IPv4                   Jul 2007


4.2.  Establishment of Bi-Directional Tunnel

   After receiving a successful Proxy Registration Reply for the Proxy
   Registration Request, the MAG sets up a tunnel to the Mobile Node's
   LMA.

   The bi-directional tunnel between the MAG and the LMA allows packets
   to flow in both directions, while the Mobile Node is connected to its
   visited link.  The tunnel endpoints are the MAG and the LMA.  All
   traffic to and from the Mobile Node is sent through this bi-
   directional tunnel.

   While the MAG is serving a Mobile Node, it MUST be able to intercept
   all packets sent from the Mobile Node and forward them out the MAG-
   LMA tunnel created for supporting that Mobile Station.  Typically,
   forwarding is based on Layer 2 information such as the source MAC
   address or ingress PPP interface.  This allows MNs with overlapping
   IP addresses to be supported.

   Any packets received on the tunnel from LMA, the MAG decapsulates
   before forwarding to the Mobile Node on its link.  Typically, the
   forwarding is based on the Destination IP address and LMA indicator
   such as tunnel interface identifier or LMA address.  This allows MNs
   with overlapping IP addresses to be supported.

4.3.  Security Association Between MAG and LMA

   The security relationship for protecting the control message
   exchanges between MAG and LMA may be either per node (i.e. same
   security association) or per MN (i.e. unique security association per
   MN).  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.  Encryption by IPSec 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 is used to authenticate the signaling.  The
   LMA does not need to be aware if the message was sent from the MN or
   MAG because the authentication operation is the same.  In the case
   when the LMA operation differs depending on the source, then some
   indication (e.g. vendor specific extension) would be needed in the
   message.






Leung, et al.            Expires January 4, 2008                [Page 9]

Internet-Draft              Proxy Mobile IPv4                   Jul 2007


4.4.  Registration Sequencing

   Since the proxy registration request is sent from different sources
   (i.e.  MAGs), a method of determining the sequence of the messages is
   required on the LMA.  The Identification field in the registration
   message provides replay protection and sequencing when the timestamp
   method is used.  This mechanism allows the LMA to know the sequence
   of messages from the same MAG or different MAGs based on the
   Identification field.  The LMA can also synchronize the MAG's clock
   by using the Identification mismatch error code in the proxy
   registration reply.  This reply message would not necessary when the
   MAGs' clocks are synchronized using Network Time Protocol [10] or
   some other method.


5.  Proxy Mobile IPv4 Extensions

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

5.1.  Proxy Mobile IPv4 Mode Extension

   The Proxy Mobile IPv4 Mode extension has the format shown in this
   section. to carry configuration information.  This extension MUST be
   included as a part of Mobile IP Registration Request or Registration
   Reply.

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


                     Proxy Mobile IPv4 Mode Extension

      Type

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

      Sub-Type

         1 (Proxy Mobile IP Mode)







Leung, et al.            Expires January 4, 2008               [Page 10]

Internet-Draft              Proxy Mobile IPv4                   Jul 2007


5.2.  PMIPv4 Per-Node Authentication Method Extension

   The Proxy Mobile IPv4 Authentication Method extension has the format
   shown in this section. to carry configuration information.  This
   extension MUST be included as a part of Mobile IP Registration
   Request or 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      |    Sub-Type   |             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)

      Method

         1 (FA-HA Authentication)

         2 (IPSec Authentication)


6.  Appearance of Being at Home Network

   Since the Mobile Node is not aware of mobility and does not
   participate in handover signaling, the network elements deceive the
   host to believe that it is stationary yet directing its traffic to
   the location where it has actually moved.  An unmodified host uses
   ARP [11] to learn the MAC address of other nodes on the subnet,
   obtains an IP address and other host configuration via DHCP [2], and
   sends link-local multicast/broadcasts.  The network's response to the
   host has to be equivalent to the situation when host is always on the
   home subnet.

6.1.  ARP Considerations

   For IEEE 802 type of access networks (e.g.  WLAN, WiMAX), the Mobile
   Node sends ARP request for host and default gateway on its subnet.



Leung, et al.            Expires January 4, 2008               [Page 11]

Internet-Draft              Proxy Mobile IPv4                   Jul 2007


   The purpose of maintaining an ARP entry is to allow the delivery of
   the packet from MN to the IP node on the link.

   For Proxy Mobile IP, the objective is to get the packet from the MN
   to the LMA.  For CNs with the same home network but roaming
   elsewhere, the LMA will tunnel the packet to them.  Otherwise, the
   LMA forwards the traffic via normal routing.

   The method to deliver the packet to the LMA depends on whether the
   MAG is on the BS or AR.  If the MAG is in the Base Station, the ARP
   entry in the MN serves no purpose since the packet will be tunneled
   to the LMA by the BS.  If the MAG is in the Access Router, then the
   Base Station needs to rewrite the destination MAC address properly to
   reach the AR.  Alternatively, a common MAC address - listened to by
   all participating AR - is sent to MN in response to an ARP Request.




   MAG@BS:    MN <-> BS/MAG <==============> LMA

       MN has ARP entries for default gateway and hosts on subnet which
       are set to some pseudo MAC address that is never used.

   MAG@AR:    MN <-> BS     <-> AR/MAG <===> LMA

       MN has ARP entries for default gateway and hosts on subnet which
       are set to some pseudo MAC address which is rewritten by BS or a
       common MAC address for ARs.



                      Figure 5: ARP Entry Management



6.2.  ICMP Considerations

   In some cases, the Mobile Node sends an ICMP Query [12] with IP TTL
   set to 1 destined to the default gateway.  This check is used to
   detect if default gateway is still reachable on the link.  The MAG
   should respond with ICMP Reply when it is providing mobility service.

6.3.  DHCP Considerations

   Proxy Mobile IP allows the Mobile Node to operate as a normal IPv4
   host using the standard IP address configuration via DHCP.




Leung, et al.            Expires January 4, 2008               [Page 12]

Internet-Draft              Proxy Mobile IPv4                   Jul 2007


   There are several methods for the network infrastructure to interface
   with the MN such that the MN believes it is always fixed on the same
   network.  The following methods are identified here, though others
   may be used as well: DHCP Proxy/Server in the MAG, independent DHCP
   procedure, and DHCP Ack trigger.

   The MN boots up and initiates DHCP.  The rest of the procedure is as
   per the description under Figure 1.

   MN boots up and obtains an IP address via DHCP normally.  Proxy
   Mobile IP is not involved in this step.  When MN moves to a new MAG,
   the MAG detects the IP address of the MN and exchanges proxy
   registration messages with the LMA to set up the routing.

   MN boots up and initiates DHCP.  The BS or AR that performed
   authentication appends the Subnet Selection Option [7] containing
   LMA's subnet.  When MAG detects the DHCP Ack from the DHCP Server, it
   sends proxy registration message to set up the routing.  Another
   method is for MAG to tunnel the DHCP messages to the LMA which acts
   as a DHCP Relay Agent.

   MN unicasts the DHCP Request to renew its IP address directly with
   the DHCP server.  This message reaches the DHCP Server directly for
   DHCP Proxy/Server case and via the tunnel between MAG and LMA for the
   other two cases.  There needs to be a method to synchronize between
   the DHCP state and PMIP state as the DHCP message is transported over
   the established PMIP tunnel.  One approach is for the MAG or LMA to
   snoop the DHCP message to detect the renew or release event.  The MAG
   and LMA can extend or release the binding based on the knowledge.

6.4.  PPP IPCP Considerations

   When MN access the network via PPP [3], LCP CHAP is used to
   authenticate the user.  After authentication, the NAS (which is the
   MAG) sends the Proxy Registration Request to the LMA, which responds
   with the Home Address in the Proxy Registration Reply.  The NAS
   informs the MN to use the Home Address during IPCP [4].  When MN
   moves to a new NAS, the same procedure happens and MN has the same IP
   address for communication.

   The message exchange is illustrated in Figure 1.

6.5.  Link-Local Multicast and Broadcast Considerations

   MAG may tunnel all packets destined to Link-Local Multicast or
   Broadcast to the LMA.  The LMA looks up the hosts which are in the
   same subnet and send a duplicated packet to each of them.




Leung, et al.            Expires January 4, 2008               [Page 13]

Internet-Draft              Proxy Mobile IPv4                   Jul 2007


7.  Proxy Mobility Agent Operation

   The role of the MAG is performing the functions of a Mobile Node.  It
   sends Proxy Registration Request to the LMA (via the Foreign Agent
   when available) to set up routing.  When there is no FA, MAG operates
   in Collocated Care-of Address mode and provides tunneling support.
   FA can provide tunneling when it is used during registration in
   accordance to RFC 3344.

   The MAG needs to know the following information for sending a proxy
   registration.

   1.  NAI

   2.  MN-HA or FA-HA Mobility Security Association, or IPSec Security
       Association

   3.  LMA Address



   This information can be downloaded from AAA server or configured by
   administrator.



8.  Local Mobility Agent Operation

   The Local Mobility Agent has the LMA functionality described in RFC
   3344.  In addition, the following feature is introduced by Proxy
   Mobile IPv4: Sequencing between MAGs and authentication between MAG
   and LMA.

8.1.  Processing Proxy Registration Requests


   When a proxy registration request is received, the LMA looks up the
   MBE indexed by the NAI.  If MBE exists, LMA 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, LMA
   accepts the registration.  LMA 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 LMA sends error code
   "Administratively prohibited (65)".  If the LMA is not enabled with
   Proxy Mobile IP, it sends a proxy registration reply with error code
   PMIP_UNSUPPORTED (Proxy Registration not supported by the Local
   Mobility Anchor).  In the case if the MAG is not allowed to send a
   proxy registration request, the LMA sends a proxy registration reply



Leung, et al.            Expires January 4, 2008               [Page 14]

Internet-Draft              Proxy Mobile IPv4                   Jul 2007


   with error code PMIP_DISALLOWED (Proxy Registrations from this mobile
   access gateway not allowed).




9.  Mobile Node Operation


   As per this specification, a Mobile Node 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 with out ever requiring it to
   participate in any mobility related signaling.

   The Mobile Node when boots up for the first time can obtain an IPv4
   address using DHCP.

   As the Mobile Node roams, it is always able to communicate using the
   DHCP leased IP address on the home network.  The MAG on the currently
   attached network signals to the LMA to ensure proper forwarding path
   for MN's traffic.

9.1.  Initial Network Access

   When the Mobile Node accesses the network for the first time and
   attaches to a network on the MAG, 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 Node will
   always be able to use that IP address anywhere in network.


9.2.  Moving to a New MAG

   When a Mobile Node moves to a new MAG from another MAG, the following
   occurs:

   The Mobile Node may perform a network access authentication with the
   attached MAG.  If the authentication fails, the Mobile Node will not
   be able to use the link.  After a successful authentication, the MAG
   will have the identifier and the other profile data of the Mobile
   Node.  The new MAG can also obtain MN's information from some form of
   context transfer mechanism.

   Once the network access authentication process is complete, the



Leung, et al.            Expires January 4, 2008               [Page 15]

Internet-Draft              Proxy Mobile IPv4                   Jul 2007


   Mobile Station 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 section 5
   "Appearance of Being At Home Network".


9.3.  Packet forwarding

   All packets that are be sent from the Mobile Node to the
   corresponding node 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.  The
   default gateway for the Mobile Node will always be its LMA.  The ARP
   Entry for LMA address is a pseudo LMA MAC address.

   Similarly, all packets sent to the Mobile Node's Home Address by the
   corresponding node will be received by the Mobile Node in the
   original form (without any tunneling overhead) on its link.

   No special operation is required by the Mobile Node to either send or
   receive packets.





10.  IANA Considerations

   This specification reserves one number for the Proxy Mobile IPv4
   Extension in Section 5 from the space of numbers for skippable
   mobility extensions (i.e., 128-255) defined for Mobile IPv4 [RFC3344]
   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
   [RFC3344] number spaces, future allocations from this number space
   require expert review [9].

10.1.  Mobile IPv4 Extension Type

   This document introduces the following Mobile IP extension type.

   Name       : Proxy Mobile IPv4 extension
   Type Value : TBD
   Section    : 5






Leung, et al.            Expires January 4, 2008               [Page 16]

Internet-Draft              Proxy Mobile IPv4                   Jul 2007


10.2.  Mobile IPv4 Error Codes

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

   Name                    Value    section first referenced
   ----                    -----    ------------------------
   PMIP_UNSUPPORTED         TBD     8.1
   PMIP_DISALLOWED          TBD     8.1



11.  Security Considerations

   The functionality in this document is protected by the Authentication
   Extensions described in RFC 3344 [5] or IPSec [8].  Each MAG needs to
   have an security association (e.g.  MN-HA, FA-HA, IPSec AH/ESP) with
   the LMA to register the MN's IP address.  The SA can be provisioned
   by the administrator.  The dynamic key distribution for this scheme
   is outside the scope of this document.



12.  Acknowledgements


13.  References

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

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

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

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

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

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

   [7]   Waters, G., "The IPv4 Subnet Selection Option for DHCP",



Leung, et al.            Expires January 4, 2008               [Page 17]

Internet-Draft              Proxy Mobile IPv4                   Jul 2007


         RFC 3011, November 2000.

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

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

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

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

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

   [13]  Navali, J. and K. Chowdhury, "IPv6 over Network based Mobile
         IPv4", draft-navali-ip6-over-netmip4-00.txt (work in progress),
         February 2006.


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










Leung, et al.            Expires January 4, 2008               [Page 18]

Internet-Draft              Proxy Mobile IPv4                   Jul 2007


   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 January 4, 2008               [Page 19]

Internet-Draft              Proxy Mobile IPv4                   Jul 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 January 4, 2008               [Page 20]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/