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]