MIP4 K. Leung
Internet-Draft G. Dommety
Intended status: Informational P. Yegani
Expires: September 29, 2008 Cisco Systems
K. Chowdhury
Starent Networks
March 28, 2008
WiMAX Forum/3GPP2 Proxy Mobile IPv4
draft-leung-mip4-proxy-mode-08.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 September 29, 2008.
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
having the Mobile IPv4 client function in a network entity to provide
mobility support for an unaltered and mobility-unaware IPv4 device.
This document also describes a particular application of PMIPv4 as
specified in the WiMAX Forum and another application that is to be
Leung, et al. Expires September 29, 2008 [Page 1]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
adopted in 3GPP2.
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 . . . . . . . . . . . . . . 11
4.1.3. Proxy Handover Support . . . . . . . . . . . . . . . . 12
4.1.4. Resource Cleanup . . . . . . . . . . . . . . . . . . . 13
4.2. Establishment of Bi-Directional Tunnel . . . . . . . . . . 14
4.2.1. Packet Forwarding . . . . . . . . . . . . . . . . . . 14
4.2.2. Broadcast and Multicast . . . . . . . . . . . . . . . 14
4.2.3. Forwarding Between Devices on same PMA . . . . . . . . 15
4.3. Security Association Between the PMA and the HA . . . . . 15
4.4. Registration Sequencing . . . . . . . . . . . . . . . . . 15
4.5. Mobile Device Interface Configuration . . . . . . . . . . 16
4.6. Dynamic HA Discovery . . . . . . . . . . . . . . . . . . . 16
5. Proxy Mobile IPv4 Extensions . . . . . . . . . . . . . . . . . 16
5.1. PMIPv4 Per-Node Authentication Method Extension . . . . . 16
5.2. Proxy Mobile IPv4 Interface ID Extension . . . . . . . . . 17
5.3. Proxy Mobile IPv4 Device ID Extension . . . . . . . . . . 18
5.4. Proxy Mobile IPv4 Subscriber ID Extension . . . . . . . . 19
5.5. PMIP Access Technology Type Extension . . . . . . . . . . 20
6. Appearance of Being at Home Network . . . . . . . . . . . . . 21
6.1. ARP Considerations . . . . . . . . . . . . . . . . . . . . 21
6.2. ICMP Considerations . . . . . . . . . . . . . . . . . . . 22
6.3. DHCP Considerations . . . . . . . . . . . . . . . . . . . 22
6.4. PPP IPCP Considerations . . . . . . . . . . . . . . . . . 23
6.5. Link-Local Multicast and Broadcast Considerations . . . . 23
7. Proxy Mobility Agent Operation . . . . . . . . . . . . . . . . 24
8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 24
8.1. Processing Proxy Registration Requests . . . . . . . . . . 25
9. Mobile Device Operation . . . . . . . . . . . . . . . . . . . 25
9.1. Initial Network Access . . . . . . . . . . . . . . . . . . 26
9.2. Mobile Device Mobility . . . . . . . . . . . . . . . . . . 26
9.3. Sending and Receiving Packet . . . . . . . . . . . . . . . 26
10. Proxy Mobile IPv4 Use Case in WiMAX . . . . . . . . . . . . . 27
10.1. Proxy Mobile IPv4 Call Flow Examples with Split PMA in
WiMAX . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11. Proxy Mobile IPv4 Use Case in 3GPP2 . . . . . . . . . . . . . 32
11.1. HO considerations in 3GPP2 . . . . . . . . . . . . . . . . 34
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
Leung, et al. Expires September 29, 2008 [Page 2]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
12.1. Mobile IPv4 Extension Types . . . . . . . . . . . . . . . 36
12.2. Mobile IPv4 Error Codes . . . . . . . . . . . . . . . . . 36
13. Security Considerations . . . . . . . . . . . . . . . . . . . 37
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . . . 41
Leung, et al. Expires September 29, 2008 [Page 3]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
1. Introduction
There are many IPv4 devices which do not have or cannot be enabled
with Mobile IPv4 [RFC3344] functionality. Yet, mobility for them is
essential. Proxy Mobile IPv4 provides mobility support without
"touching" these devices. The scheme is based on network entities
which 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 entitiy 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 entities because the mobility
protocol has the functions needed to set up the route and tunneling
endpoints for the mobile device's IP address and to deliver
configuration parameters (e.g. DNS server addresses, default
gateway) for enabling the mobile device's IP stack. When Mobile IPv4
is used in this way, the security association is between the PMA and
the HA because these entities are the signaling endpoints. Also,
when the mobile device moves to a new PMA, the sequencing of messages
sourced from multiple PMAs needs to be handled properly by the HA.
This document describes how the network entities, PMA and HA, provide
mobility management for the mobile device. It is organized to cover
the generic functionality of Proxy Mobile IPv4 and also the specifics
pertaining to WiMAX (Section 10) and 3GPP2 (Section 11).
2. Conventions used in this document
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
The following new terminology and abbreviations are introduced in
this document and all other general mobility related terms as
Leung, et al. Expires September 29, 2008 [Page 4]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
defined in Mobile IPv4 specification [RFC3344].
Mobile Device
The mobile device is used to refer to an IPv4 device with its
mobility provided by the network. The mobile device is not
required to participate in any mobility related signaling for
achieving mobility for an obtained IP address.
Proxy Mobile IPv4 Client (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 [RFC3344] is used
in the Proxy Mobile IPv4 scheme. It is the topological anchor
point for the mobile device's home network and is the entity
that manages the mobile device's reach-ability state. The
additional capabilities for supporting Proxy Mobile IPv4 in the
Home Agent are defined in this document.
Foreign Agent (FA)
The Foreign Agent that is defined in [RFC3344] is used in the
Proxy Mobile IPv4 scheme. It is either collocated with or
separate from the PMIP Client. 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 September 29, 2008 [Page 5]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
referred as a split PMA. A PMIP client may have association
with multiple FAs, and vice versa.
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 September 29, 2008 [Page 6]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
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, although the network treats each access
interface independently. This feature can be supported with
the use of the PMIP Access Technology Type Extension
(Section 5.5).
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 [DSMIPv4].
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
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 defined in standards organization specification
Leung, et al. Expires September 29, 2008 [Page 7]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
(e.g. WiMAX R4 reference point) 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.
When the various network entities are not collocated, any sharing of
parameters or other state information between them is out of the
scope of this draft.
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 September 29, 2008 [Page 8]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
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/authorizes 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
[RFC1994] or PAP [RFC1334] if PPP [RFC1331] is used or EAP [RFC3748]
over foo (foo being the specific access technology or PANA
[RFC4058]). The AR acts as the NAS (Network Access Server) in this
step.
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
[RFC1332] or DHCP [RFC2131]. 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 sends the DHCP
Ack message to the DHCP client after PMIPv4 signaling had completed.
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 13). The derivation and distribution of the MN-HA or FA-HA
key is outside the scope of this document.
4. The home agent sets up the mobility binding entry for the mobile
device after assigning an IP address or authorizing the requested
Home Address. The home agent may also assign a GRE key in this step
(if GRE tunneling is used between the PMA and HA). The HA returns
Leung, et al. Expires September 29, 2008 [Page 9]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
the Home Address, the GRE key (if applicable) in the Proxy
Registration Request (PRRP) to the PMA. If the requested Home
Address is not authorized, the home agent denies the registration
with error code 129 (administratively prohibited). After the PMA
processes the PRRP, the forwarding path for the Home Address between
the PMA and HA is established. A GRE tunnel may be used between the
PMA and the HA [MIP4GREKEY]. The event completes the Proxy Mobile
IPv4 signaling for initial network attachment.
5. After the Proxy Mobile IPv4 registration exchange, the AR
provides the IP address to the mobile device in response to step 2.
For IPCP, the NAS replies to the PPP client with 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
relayed 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. Regardless of the sequence
of PMIP signaling and DHCP exchanges, the interaction between PMIP
and DHCP involves in the same IP address for Home Address field and
yiaddr field, respectively.
6. At this step, the mobile device's IP stack is configured with an
IP address that has a forwarding path between the AR/PMA and HA.
Also, the host configuration such as DNS servers is configured at
this time. Now that the IPCP or DHCP procedure has completed, the
mobile device is ready to receive or send IP packets. If DHCP is
used, the DHCP client renews the IP address by sending a DHCP Request
directly to the DHCP server. The lease for the IP address is
extended when a DHCP Ack from the DHCP server is received by the DHCP
client.
Leung, et al. Expires September 29, 2008 [Page 10]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
4.1.2. Proxy Registration Renewal
+----+ +-------+ +-----+
| | | AR / | | |
| MN | | PMA | | HA |
| | | | | |
+----+ +-------+ +-----+
| | |
| | 1 |
| |----------------------->|
PMIP | | |
Renewal | | 2 |
| |<-----------------------|
| | |
| | |
Figure 2: Network Connection Maintenance
The network connection maintenance procedure is described below. As
long as the mobile device remains attached to the AR, the Proxy
Mobile IPv4 session is maintained by re-registration 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.
Leung, et al. Expires September 29, 2008 [Page 11]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
4.1.3. Proxy Handover Support
+----+ +-------+ +-------+ +-----+
| | | New | | Old | | |
| MN | | AR / | | AR / | | HA |
| | | PMA | | PMA | | |
+----+ +-------+ +-------+ +-----+
| | | |
| 1 | | |
Authentication |<------------->| | |
| | | |
| | 2 | |
+-> | |-------------------------->|
PMIP | | | | |
| | | 3 | |
+-> | |<--------------------------|
| | | |
| 4 | | |
Data Forwarding |<------------->|<=========================>|
| | | |
Figure 3: AR Handover
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.
Leung, et al. Expires September 29, 2008 [Page 12]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
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 6.1, ICMP
Section 6.2 and DHCP Section 6.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.
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 [RFC3543]) to the
Leung, et al. Expires September 29, 2008 [Page 13]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
old PMA (i.e. specifically to the Foreign Agent entity) in order to
clean up unused resources in an expeditious manner.
2. The old PMA removes the PMIP 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
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. Broadcast and Multicast
Broadcast packet processing for DHCP and ARP messages are described
in Section 6.3 and Section 6.1, respectively. For other types of
broadcast packets, the PMA and HA process them in accordance to
[RFC3344], [RFC3024], and [MIP4MCBC]. Only the Direct Encapsulation
Delivery Style is supported as there is no encapsulation for the
packets between the mobile device and PMA.
Leung, et al. Expires September 29, 2008 [Page 14]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
4.2.3. 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 [RFC3543]. 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.
The creation of the security association may be assisted by the AAA
server at the time of access authentication.
4.4. Registration Sequencing
The Identification field in the registration message provides replay
protection and sequencing when the timestamp method is used. This
mechanism allows the HA to know the sequence of messages from the
same PMA or different PMAs based on the Identification field. The HA
can also synchronize the PMA's clock by using the Identification
mismatch error code in the proxy registration reply. This reply
message would not be necessary when the PMA's clocks are synchronized
using Network Time Protocol [RFC1305] or some other method. Note
that the use of nonce for sequencing and replay protection is outside
of scope.
The method above is sufficient when there is a single source for
signaling as in the split PMA case. However in the integrated PMA
case, the proxy registration request is sent from different sources
(i.e. different PMAs). If the previous PMA is unaware that the
mobile device has moved away and continues to send re-registration,
then HA would be misinformed on the location of the device.
Therefore, an integrated PMA MUST confirm that the mobile device is
Leung, et al. Expires September 29, 2008 [Page 15]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
still attached before sending a proxy registration request.
Note that for split PMA model as used in WiMAX Forum, see Section 10,
the PMIP Client remains anchored during handover, see Section 10.1.
In this case, the PMIP Client is the only source of the PRRQ.
However, there are cases such as PMIP Client relocation and
uncontrolled handover event when more than one PMA performs
registration. The same method for the integrated PMA is used to
ensure proper sequencing of registration on the HA.
4.5. Mobile Device Interface Configuration
Typically, the mobile device's interface needs to be configured with
an IP address, network prefix, default gateway, and DNS server
addresses before the network connection can be enabled to be used for
communication. For some IP stacks, the default gateway IP address
has to be on the same subnet as the mobile device's IP address. When
the Home Agent's IP address is not on the same subnet as the Home
Address, the vendor specific extensions (e.g. [RFC4332]) or other
methods MAY be used by the PMA to obtain the default gateway.
4.6. Dynamic HA Discovery
The PMA can perform dynamic HA discovery by sending the registration
with Home Agent field set to 0.0.0.0 or 255.255.255.255. The Home
Agent responds with its IP address in the Home Agent field as
specified in Dynamic HA Assignment [RFC4433].
5. Proxy Mobile IPv4 Extensions
The following PMIPv4 extensions are not required for base
functionality but may be used in some cases where such features are
applicable. They are included before the authentication extension
(e.g. MN-HA or FA-HA authentication extension) in the registration
message.
5.1. PMIPv4 Per-Node Authentication Method Extension
The Proxy Mobile IPv4 Authentication Method extension indicates
alternative methods for authenticating the registration besides the
default MN-HA Authentication Extension as specified in RFC 3344.
This extension MUST be included in the Registration Request and
Registration Reply when the security association for authenticating
the message is between the PMA and HA on a per node basis. This
means that a common key or set of keys (indexed by the SPI) are used
for message authentication by the PMA and HA. The key is independent
of the mobile device which is identified in the registration.
Leung, et al. Expires September 29, 2008 [Page 16]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Method |
+-+-+-+-+-+-+-+-+
PMIPv4 Per-Node Authentication Method Extension
Type
47 (Proxy Mobile IPv4 Non-skippable Extension)
Sub-Type
1 (PMIPv4 Per-Node Authentication Method)
Length
1
Method
0: Reserved
1: FA-HA Authentication
2: IPSec Authentication
5.2. Proxy Mobile IPv4 Interface ID Extension
The Proxy Mobile IPv4 Interface ID extension identifies the interface
address of the device used to attach to the network. The information
MAY be included in the Registration Request when the PMA is aware of
it.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PMIPv4 Interface ID Extension
Leung, et al. Expires September 29, 2008 [Page 17]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
Type
147 (Proxy Mobile IPv4 Skippable Extension)
Length
The length of the extension in octets, excluding Type and
Length fields.
Sub-Type
1 (PMIPv4 Interface ID)
Identifier
A variable-length octet sequence that contains an identifier of
the interface.
5.3. Proxy Mobile IPv4 Device ID Extension
The Proxy Mobile IPv4 Device ID extension identifies the device used
to connect to the network. The information MAY be included in the
Registration Request when the PMA is aware of it.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | ID-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PMIPv4 Device ID Extension
Type
147 (Proxy Mobile IPv4 Skippable Extension)
Length
The length of the extension in octets, excluding Type and
Length fields.
Leung, et al. Expires September 29, 2008 [Page 18]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
Sub-Type
2 (PMIPv4 Device ID)
ID-Type
0: Reserved
1: Ethernet MAC address
2: Mobile Equipment Identifier (MEID)
3: International Mobile Equipment Identity (IMEI)
4: Electronic Serial Number (ESN)
Identifier
A variable-length octet sequence that contains an identifier of
the type indicated by the ID-Type field.
5.4. Proxy Mobile IPv4 Subscriber ID Extension
The Proxy Mobile IPv4 Subscriber ID extension identifies the mobile
subscription. The information MAY be included in the Registration
Request when the PMA is aware of it.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | ID-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PMIPv4 Subscriber ID Extension
Type
147 (Proxy Mobile IPv4 Skippable Extension)
Length
The length of the extension in octets, excluding Type and
Length fields.
Leung, et al. Expires September 29, 2008 [Page 19]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
Sub-Type
3 (PMIPv4 Subscriber ID)
ID-Type
0: Reserved
1: International Mobile Subscriber Identity (IMSI)
Identifier
A variable-length octet sequence that contains an identifier of
the type indicated by the ID-Type field.
5.5. PMIP Access Technology Type Extension
The Proxy Mobile IPv4 Access Technology Type extension indicates the
type of radio access technology on which the mobile device is
attached. This extension MAY be included in the Registration Request
when the PMA is aware of the information. The HA can provide
mobility on the same access technology type for a mobile device with
multiple interfaces assuming each interface is connected on a
different access technology type. The HA does not include the
extension in the associated Registration Reply.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Tech-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PMIP Access Technology Type Extension
Type
147 (Proxy Mobile IPv4 Skippable Extension)
Length
2
Sub-Type
4 (Access Technology Type)
Leung, et al. Expires September 29, 2008 [Page 20]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
Tech-Type
0: Reserved
1: 802.3
2: 802.11a/b/g
3: 802.16e
4: 802.16m
5: 3GPP EUTRAN/LTE
6: 3GPP UTRAN/GERAN
7: 3GPP2 1xRTT/HRPD
8: 3GPP2 UMB
6. Appearance of Being at Home Network
Since the Mobile Node is not aware of its mobility and does not
participate in handover signaling, the network entities emulate the
home network to the mobile device attached on the network. From the
mobile device's perspective, it operates as 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 ([RFCARP]), obtains an IP
address and other host configuration via DHCP ([RFC2131]), and sends
link-local multicast and broadcast packets. The network's response
to the host is equivalent to the situation when host is on the home
network. When the link state changes, some hosts use ARP, ICMP,
and/or DHCP to detect if it has changed the point of attachment on
the network.
6.1. ARP Considerations
For IEEE 802 type of access networks (e.g. WLAN, WiMAX Ethernet
Convergence Sublayer), the mobile device sends ARP 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
Leung, et al. Expires September 29, 2008 [Page 21]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
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.
6.2. ICMP Considerations
For movement detection, certain types of network stack on the mobile
device will send an ICMP request [RFCICMP] to the default gateway
after detecting the link went down and up. The IP TTL in the message
is set to 1 to check if the default gateway is still directly
reachable on the access network. The PMA MAY send an ICMP reply when
it is providing Proxy Mobile IPv4 service for the mobile device.
This response confirms to the mobile device that it has remained on
the home network after link state change.
General ICMP traffic is handled as normal IP packets and tunneled
between PMA and HA.
6.3. DHCP Considerations
DHCP [RFC2131] is used to obtain an IP address and other host
configuration parameters for a mobile device. The mobile device is
expected to behave as a normal DHCP client when connected to the
network with Proxy Mobile IPv4 service. There are two DHCP phases:
bootup and renewal/release. The bootup procedure relies on the DHCP
relay agent to obtain a lease on the IP address for the DHCP client
from the DHCP server. The DHCP client directly renews and releases
the lease with the DHCP server.
In Proxy Mobile IPv4, the mobile device boots up on a network that is
not the home network associated with the leased IP address. Also,
the mobile device can move to other networks that are not related to
that IP address. Yet, the DHCP client on the mobile device continues
to operate as a stationary device that is directly on the network
associated with its IP address. The PMA and HA create the
transparency of the remote home network and mobility events by
providing the expected network response to the DHCP client.
Leung, et al. Expires September 29, 2008 [Page 22]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
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
relayed to the DHCP server in the HA. When the DHCP lease time
expires for the mobile device's IP address or the DHCP release
message is received on the HA, the HA deletes the mobility binding
entry for the mobile device and sends registration revocation
[RFC3543] to the AR.
6.4. PPP IPCP Considerations
When the mobile device access the network via PPP [RFC1331], 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 [RFC1332]. When mobile device moves to
a new NAS, the same procedure happens and mobile device has the same
IP address for communication.
The message exchange is illustrated in Figure 1.
6.5. Link-Local Multicast and Broadcast Considerations
Depending on configuration policies, the PMA may tunnel all packets
destined to Link-Local Multicast or Broadcast to the HA. The HA
looks up the hosts which are in the same subnet and send a duplicated
packet to each of them.
Leung, et al. Expires September 29, 2008 [Page 23]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
7. Proxy Mobility Agent Operation
The PMA performs the functions of a Mobile Node entity as described
in RFC 3344 with the exceptions identified below.
- 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 10).
The PMA needs to know the following information at a minimum for
sending a proxy registration:
1. NAI of the mobile device
2. MN-HA security association when per-mobile device security
association is used
3. FA-HA Mobility Security Association or IPSec Security Association
when per-node security association is used. Note, 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.
8. Home Agent Operation
The Home Agent has the functionalities as described in RFC 3344
[RFC3344]. In addition, the following features are introduced by
Proxy Mobile IPv4:
1. Sequencing between PRRQs from multiple PMAs. For the integrated
PMA case, there is a period after handover that may result in both
the new PMA and old PMA sending PRRQs. It is imperative that the old
Leung, et al. Expires September 29, 2008 [Page 24]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
PMA confirm that the mobile device is attached before sending a PRRQ
when re-registration timer expires. This would ensure that the HA
only receives registration from PMA that is serving the mobile
device.
2. Authentication of PRRQs based on per Node Security Association
(FA-HA AE or IPsec AH/ESP) is applicable in the integrated PMA case.
The presence of MN-HA AE or MN-AAA AE in the PRRQ is not necessary in
this case. Since PMIP 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.
8.1. Processing Proxy Registration Requests
When a proxy registration request is received, the HA looks up the
mobility binding entry indexed by the NAI. If the entry exists, HA
compares the Sequence Numbers between the message and 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)".
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.
9. Mobile Device Operation
As per this specification, a mobile device would function as a normal
IPv4 host. The required behavior of the node will be consistent with
the base IPv4 specification [1]. The mobile station will have the
Leung, et al. Expires September 29, 2008 [Page 25]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
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.
9.1. Initial Network Access
When the mobile device accesses the network for the first time and
attaches to a network on the PMA, it will present its identity in the
form of NAI to the network as part of the network access
authentication process.
Once the address configuration is complete, the mobile device will
always be able to use that IP address anywhere in the network.
9.2. Mobile Device Mobility
When a mobile device moves to a new PMA from another PMA, the
following occurs:
The mobile device may perform a network access authentication with
the new AR/PMA. If the authentication fails, the mobile device will
not be able to use the link. After a successful authentication, the
new PMA will have the identifier and the other profile data of the
mobile device. The new PMA can also obtain 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 6) section.
9.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
Leung, et al. Expires September 29, 2008 [Page 26]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
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.
10. 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
specification from WiMAX Forum is [NWG].
The Proxy Mobile IPv4 protocol is used over NWG reference point 3
(R3). Most of the Proxy Mobile IPv4 related procedures and
requirements are described in reference to mobility management over
R3.
The Proxy Mobile IPv4 use case in WiMAX Forum specification is
illustrated in the following diagram:
Leung, et al. Expires September 29, 2008 [Page 27]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
|
| CSN
|
|
+-------+ | +-------+
| | | | |
|AAAV |--------------|------------| AAAH |
| | | | |
| | | | |
+-------+ | +-------+
| | |
| | |
| | |
+------------------+ | |
| +-------+ | | |
| | NAS | | | |
| | PMIP | ASN1 | | |
| | Client| | | |
| +-------+ | | |
| | | | |
| | R4 | | |
| +-------+ | | +------+
+----+ | | FA, | | | PMIPv4 | |
| MN |-------| DHCP |---------------------------| HA |
+----+ | | Relay/| | | R3 | |
| | Server| ASN2 | | +------+
| +-------+ | |
| | |
+------------------+
Split PMA
WiMAX NWG network configuration for PMIP use
As shown in the figure above, WiMAX NWG uses the split PMA model.
The PMIP Client is collocated with the NAS in ASN1 (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 Connectivity Service Network
(CSN). The MN attaches to a 802.16 radio in the ASN2 (aka Anchor
Data Path Function). The radio (base station) connects to the Anchor
Data Path Function (A_DPF) in ASN2 which in turn connects to
Authenticator ASN (NAS) in ASN1. ASN1 authenticates and authorizes
the MN. The AAA infrastructure is used to authenticate and authorize
the MN.
Leung, et al. Expires September 29, 2008 [Page 28]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
Note that, during initial network entry by the MN, the PMA can be an
integrated PMA with all the functions collocated in ASN1. Due to
mobility, the FA part of the PMA may have to be relocated to a more
optimized location for better bearer management. However, to
describe the WiMAX specific use case for Proxy Mobile IPv4, we will
use the split PMA model since it is more generic representation of
the WiMAX NWG mobility framework.
WiMAX NWG specification [NWG], 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 [NWG], stage-3
specification.
Mobile IPv4 Registration Revocation is optionally supported in WiMAX.
The security association for this is per Node. It is provided with
FA-HA AE. The FA-HA key is also bootstrapped via the same key
hierarchy that is described in section 4.3 of [NWG].
The proxy Mobile IPv4 operation in WiMAX NWG is aligned with the
basic proxy Mobile IPv4 operation as described in section 4 of this
document. There are specific considerations for WiMAX NWG 1.0.0 use
of proxy Mobile IPv4. These are listed below:
1. Use of per MS SA for proxy Mobile IPv4 registration. In this
case, MN-HA AE is used.
2. Use of split PMA to handle FA relocation while PMIP Client
remains anchored with the NAS (Authenticator ASN).
3. Only the Proxy Mobile IPv4 Access Technology Type Extension
defined in this document is used in NWG specification [NWG].
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 specification [NWG].
6. In order to handle inter ASN (inter Access Router) handover, and
still allow the MN to use the same DHCP server's IP address that was
sent in DHCPOFFER/ACK, the DHCP server (aka proxy) functions in the
ASN 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.
Leung, et al. Expires September 29, 2008 [Page 29]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
10.1. Proxy Mobile IPv4 Call Flow Examples with Split PMA in WiMAX
Since the WiMAX uses split PMA model, the call flows involve WiMAX
proprietary signaling between PMIP Client and FA within the PMA. The
following call flows illustrate this.
Proxy Handover Operation in WiMAX with Split PMA
Split PMA
+-----------------------------------+
+----+ | +------+ +------+ +-----+ | +-----+
| | | | NAS/ | | Old | | New | | | |
| MN | | | PMIP | | FA | | FA | | | HA |
| | | |Client| | | | | | | |
+----+ | +------+ +------+ +-----+ | +-----+
| +----|------------|------------|----+ |
| | | PMIP Tunnel |
| | |<=======================>|
| | | | |
| | | R4 tunnel | |
| | |<==========>| |
| | 1 | | |
|<---------------------------------->| |
| | | | |
| | | 2 | |
| | |<---------->| |
| | 3 | | |
| |<----------------------- | |
| | | | |
| | 4 | | |
+-> | |------------------------>| |
| | | | | 5 |
| | | | |----------->|
| | | | | |
PMIP | | | | | 6 |
| | | | |<-----------|
| | | | | |
| | | 7 | | |
+-> | |<------------------------| |
| | | | |
| | | 8 | |
| | |<---------->| |
| | | | |
| 9 | | |PMIP Tunnel |
Data |<---------------------------------->|<==========>|
Forwarding | | | | |
Leung, et al. Expires September 29, 2008 [Page 30]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
Figure 5: AR Handover in WiMAX
In this scenario, the MN has moved to a new FA's area (known as Data
Path Function in WiMAX). The old FA and the new FA interact with
each other and also with the PMIP Client over WiMAX specified R4
reference point to perform the handover. The steps are described
below:
1. The mobile device establishes L2 link with a base station (not
shown) which connects to a new FA (aka new Data Path Function in
WiMAX). Note that in this case, the MN does not perform
authentication and authorization. The PMIP Tunnel remains between
the Old FA (aka old Data Path Fucntion in WiMAX). The data flows
through PMIP tunnel between the HA and the old FA and the WiMAX
specific R4 tunnel between the old FA and the new FA and from new FA
to the MN.
2. The new FA interacts with the old FA using WiMAX specific R4
reference point to initiate the handover process.
3. The new FA uses the WiMAX specific R4 reference point to request
the PMIP Client to begin the PMIP handover.
4. Triggered by step 3 the PMIP Client sends an PRRQ to the new FA.
The PRRQ contains the FA-CoA of the new FA. The Home Address field
is set to the address the assigned IP address of the mobile node.
The PRRQ is embedded in the WiMAX specific R4 packet.
5. The new FA forwards the PRRQ to the HA.
6. The home agent updates the existing mobility binding entry for
the mobile device upon processing the PRRQ. The home agent responds
back to the new FA with PRRP.
7. The new FA forwards the PRRP after encapsulating it in a WiMAX
specific R4 packet to the PMIP Client.
8. The new FA and the old FA exchange WiMAX R4 specific messages
between them to confirm the handover. The old FA cleans up it's
resources for the MN. The R4 bearer forwarding also stops at this
point.
9. The forward and reverse direction traffic flows via the new FA.
The handover is complete at this point.
Leung, et al. Expires September 29, 2008 [Page 31]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
11. 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
RAN Core
+-------+ +------+
+----+ | AGW/ | PMIPv4 | |
| MN |------| PMA |-----------------------| HA |
+----+ | | | |
| | +------+
+-------+
Integrated PMA
Leung, et al. Expires September 29, 2008 [Page 32]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
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
([3GPP2]).
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:
+----+ +-------+ +-------+ +------+
| | | | | | | |
| MN | | BS/ | | HAAA | | AGW/ |
| | | PMA | | | | HA |
+----+ +-------+ +-------+ +------+
| | | |
| 1a | 1b | |
|<------------->|<----------->| |
| | | |
| 2 | | |
|-------------->| | |
| | 3 | |
| |----------------------->|
| | | |
| | 4 | |
| |<-----------------------|
| 5 | | |
|<--------------| | |
| | | |
| 6 | | |
Leung, et al. Expires September 29, 2008 [Page 33]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
|<======================================>|
| | | |
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
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.
11.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
Leung, et al. Expires September 29, 2008 [Page 34]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
case:
+----+ +-------+ +-------+ +-------+
| | | | | | | |
| MN | | New | | AGW/ | | Old |
| | | PMA/BS| | HA | | PMA/BS|
+----+ +-------+ +-------+ +-------+
| | | |
| | 1 | |
| |------------->| |
| | | |
| | | |
| | o 2 |
| | | |
| | | |
| | 3 | |
| |<-------------| |
| | | |
| | | |
| | 4 | |
| |<----------------------->|
| | | |
| | | |
| | | o 5
| | | |
| | | |
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.
Leung, et al. Expires September 29, 2008 [Page 35]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
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.
12. IANA Considerations
This specification reserves 47 for the Proxy Mobile IPv4 Non-
skippable Extension and 147 for Proxy Mobile IPv4 Skippable Extension
in Section 5. The ranges for Mobile IPv4 [RFC3344] extension types
are defined at http://www.iana.org/assignments/mobileip-numbers.
This specification also creates a new subtype space for the type
number of the extensions. The subtype value 1 is defined for the
PMIPv4 Non-skippable Extension. The subtype values 1 to 4 are
defined for the PMIPv4 Skippable Extension. Similar to the
procedures specified for Mobile IPv4 number spaces, future
allocations from the number space require expert review [RFC2434].
12.1. Mobile IPv4 Extension Types
This document introduces the following Mobile IP extension types.
Name : Proxy Mobile IPv4 Non-skippable Extension
Type Value : 47
Section : 5
Name : Proxy Mobile IPv4 Skippable Extension
Type Value : 147
Section : 5
12.2. Mobile IPv4 Error Codes
This document introduces the following error code that can be
returned by the HA in a Proxy Registration Reply.
Name Value First referenced
---- ----- ----------------
Leung, et al. Expires September 29, 2008 [Page 36]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
PMIP_UNSUPPORTED TBD 8.1
PMIP_DISALLOWED TBD 8.1
13. Security Considerations
The functionality in this document is protected by the Authentication
Extensions described in RFC 3344 [RFC3344] or IPSec [RFC2401]. Each
PMA needs to have an security association (e.g. MN-HA, FA-HA, IPSec
AH/ESP) with the HA to register the MN's IP address. The security
association can be provisioned by the administrator, or dynamically
derived. The dynamic key derivation and distribution for this scheme
is outside the scope of this document.
14. Acknowledgements
The authors would like to thank the following individuals for their
review, comments, and suggestions to improve the content of this
document.
Shahab Sayeedi (Motorola), Alper Yegin (Samsung), Premec Domagoj
(Siemens), Michael Hammer (Cisco), Jun Wang (Qualcomm), Jayshree
Bharatia (Nortel), Semyon Mizikovsky (Alcatel-Lucent), Federico De
Juan Huarte (Alcatel-Lucent), Paula Tjandra (Motorola), Alice Qinxia
(Huawei), Howie Koh (Greenpacket), John Zhao (Huawei), Pete McCann
(Motorola), and Sri Gundavelli (Cisco).
15. References
[3GPP2] "3GPP2 UMB CAN architecture", ftp://ftp.3gpp2.org/TSGX/
Projects/X.P0054%20Evolved%20Wireless%20IP%20Network/
X.P0054-0%20v1.0/RF/.
[DSMIPv4] Tsirtsis, G., "Dual Stack Mobile IPv4",
draft-ietf-mip4-dsmipv4-06.txt (work in progress),
February 2008.
[MIP4GREKEY]
Yegani, P., "GRE Key Extension for Mobile IPv4",
draft-yegani-gre-key-04.txt (work in progress), Jun 2007.
[MIP4MCBC]
Chakrabarti, S., "IPv4 Mobility extension for Multicast
Leung, et al. Expires September 29, 2008 [Page 37]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
and Broadcast Packets", draft-chakrabarti-mip4-mcbc-02.txt
(work in progress), Nov 2007.
[NWG] "WiMAX Forum Network Architecture (Stage 3: Detailed
Protocols and Procedures) Release 1.1.2", http://
www.wimaxforum.org/technology/documents/
WiMAX_End-to-End_Network_Systems_Architecture_Stage_2-
3_Release_1.1.0.zip, Nov 2007.
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.
[RFC1331] Simpson, W., "The Point-to-Point Protocol (PPP) for the
Transmission of Multi-protocol Datagrams over Point-to-
Point Links", RFC 1331, May 1992.
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992.
[RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols",
RFC 1334, October 1992.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP",
RFC 3011, November 2000.
[RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP,
revised", RFC 3024, January 2001.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
Leung, et al. Expires September 29, 2008 [Page 38]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
Network Address Translation (NAT) Devices", RFC 3519,
May 2003.
[RFC3543] Glass, S. and M. Chandra, "Registration Revocation in
Mobile IPv4", RFC 3543, August 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang,
"Protocol for Carrying Authentication for Network Access
(PANA) Requirements", RFC 4058, May 2005.
[RFC4332] Leung, K., Patel, A., Tsirtsis, G., and E. Klovning,
"Cisco's Mobile IPv4 Host Configuration Extensions",
RFC 4332, December 2005.
[RFC4433] Kulkarni, M., Patel, A., and K. Leung, "Mobile IPv4
Dynamic Home Agent (HA) Assignment", RFC 4433, March 2006.
[RFCARP] Plummer, D., "An Ethernet Address Resolution Protocol",
RFC 826, November 1982.
[RFCICMP] Postel, J., "Internet Control Message Protocol", RFC 792,
September 1981.
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 September 29, 2008 [Page 39]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
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 September 29, 2008 [Page 40]
Internet-Draft WiMAX Forum/3GPP2 PMIPv4 March 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Leung, et al. Expires September 29, 2008 [Page 41]