Proxy Mobile IPv6 – Wikipedia
Proxy Mobile IPv6 (or PMIPv6, or PMIP) is a network-based mobility management protocol standardized by IETF and is specified in RFC 5213. It is a protocol for building a common and access technology independent of mobile core networks, accommodating various access technologies such as WiMAX, 3GPP, 3GPP2 and WLAN based access architectures. Proxy Mobile IPv6 is the only network-based mobility management protocol standardized by IETF.
Introduction[edit]
Network-based mobility management enables the same functionality as Mobile IP, without any modifications to the host’s TCP/IP Protocol stack. With PMIP the host can change its point-of-attachment to the Internet without changing its IP address. Contrary to Mobile IP approach, this functionality is implemented by the network, which is responsible for tracking the movements of the host and initiating the required mobility signalling on its behalf. However, in case the mobility involves different network interfaces, the host needs modifications similar to Mobile IP in order to maintain the same IP address across different interfaces.
The “SaMOG” (S2a Mobility based on GTP) study item in 3GPP defines the interworking between mobile packet core and a trusted WLAN access network (3GPP TR 23. 852). The interface that SaMOG defines for this interworking is the 3GPP S2a GTP interface.
Proxy Mobile IPv6 Deployment Models[edit]
+——–+ _—-_ | +——–+ _—-_
| | _()_ | | | _()_
| |—-( Internet) | | |—-( Internet)
| (LMA) | (_ _) | | (LMA) | (_ _)
| | ‘—-‘ | | | ‘—-‘
+——–+ | +——–+
| | |
— — — — — | _—-_
— — | _()_
— — | ( internet)
— IP Network — | (_ _)
— — | ‘—-‘
— — | |
— — — — — | +———–+
/ \ | | MAG |—-
+————-+ +————-+ | +———–+ |— (Session Chaining)
| | | | | | LMA |—-
| MAG | | MAG | | +———–+
| | | | | |
+————-+ +————-+ | _—-_
| | | | | _()_
+—–+ +—–+ +—–+ +—–+ | –(IP Network)–
| AP | | AP | | AP | | AP | | | (_ _) |
| (L2)| | (L2)| | (L2)| | (L2)| | | ‘—-‘ |
+—–+ +—–+ +—–+ +—–+ | +—–+ +—–+…. | | MAG | | MAG |
/ \ / \ / \ / \ | +—–+ +—–+
MN | /\
| MN
|
Proxy Mobile IPv6: Flat Domain Model | Proxy Mobile IPv6: Domain Chaining
Key Properties of Proxy Mobile IPv6 Technology[edit]
Based on Open Internet Standards
No client software requirement
IP Address Continuity
Session Continuity when roaming within a single access technology domain
The mobile node can be an IPv4-client, IPv6 client or a dual stack client
The transport network between LMA (Local Mobility Anchor) and MAG (Mobile Access Gateway) can be IPv4 or IPv6
The tunnel between the LMA and MAG is a shared tunnel
The tunnel between LMA and MAG can be based on GRE or IP-in-IP
No packet fragmentation, as PMIP advertises adjusted MTU values on the access side
Extremely Light Weight Protocol, MAG function can be implemented on a low-cost access point
Minimal Handover Latency
Signaling semantics are based on IPv6, but can be enabled on an IPv4 network
PMIPv6 signaling can be protected using standard IPsec transport mode ESP
Natural Support for Client Mobility. The LMA is a Mobile IPv6 Home Agent
Protocol Interface supported in 3GPP LTE Architecture
Standard Protocol Glue for linking access technology domains
Industry Wide Participation in Standardization
Adopted in 3GPP, WiMAX and 3GPP2 Architectures
Central traffic aggregation for charging, policy enforcement, LI and DPI Enforcement
Supported in all 3GPP LTE Packet Data Gateways (LMA function in PDN Gateway)
Future proof
Proxy Mobile IPv6: Technology Overview[edit]
Functional Entities[edit]
The PMIPv6 architecture defines following functional entities:
Local Mobility Anchor (LMA)
Mobile Access Gateway (MAG)
Mobile Node (MN)
Correspondent Node (CN)
Messaging Call Flows[edit]
Protocol Operation[edit]
A mobile host enters a PMIP domain
A Mobile Access Gateway on that link checks host authorization
A mobile host obtains an IP address
A Mobile Access Gateway updates a Local Mobility Anchor about the current location of a host
Both MAG and LMA create a bi-directional tunnel
A Mobile Access Gateway sends a Router Advertise message to MN with Care-of-Address
Access Authentication[edit]
Access authentication and mobile node’s identity
Mobile node’s policy profile
MAG and Authenticator Collocation
Security Considerations[edit]
Control Plane Security
Data Plane Security
Address Assignment[edit]
IPv4 Address Assignment over DHCPv4
Stateless Autoconf for IPv6
Proxy Mobile IPv6: Technology Applications[edit]
Selective IP Traffic Offload Support with Proxy Mobile IPv6
Network-based Mobility Management in a local domain (Single Access Technology Domain)
Inter-technology handoffs across access technology domains (Ex: LTE to WLAN, eHRPD to LTE, WiMAX to LTE)
Access Aggregation replacing L2TP, Static GRE, CAPWAP based architectures, for 3G/4G integration and mobility
Selective IP Traffic Offload (SIPTO) Support with Proxy Mobile IPv6[edit]
Mobile Operators today are facing two fundamental challenges:
There is availability of only finite amount of licensed spectrum, limiting the number of mobile nodes that can be active at a point of time in the macro network. This is proving to be a major issue in high-density areas, such as San Francisco city.
The exponential growth in the mobile data traffic is creating significant capacity problems in the mobile packet core
To address these scaling challenges, mobile operators are exploring new technology approaches for expanding their network coverage by integrating alternative access technologies into a common mobile core. Specifically, Wireless LAN networks based on IEEE 802. 11 standards is showing lot of promise.
Secondly, for addressing the issue with the massive growth in mobile data traffic, mobile operators are exploring new ways to offload some of the IP traffic flows at the nearest WLAN access edge wherever there is an internet peering point, as opposed to carrying it all the way to the mobility anchor in the home network. Not all IP traffic needs to be routed back to the home network; some of the non-essential traffic which does not require IP mobility support can be offloaded at the access edge gateway. This approach provides greater leverage and efficient usage of the mobile packet core with increased overall network capacity and by lowering transport costs. Approaches such as, Selective IP Traffic Offload Option can be provide the basic offload semantics.
How to Implement Proxy Mobile IPv6[edit]
Mobile Access Gateway[edit]
Functional Block
Requirement
Platform API
Description
Trigger Handler
Events: MN-ATTACHED, MN-DETACHED Parameters: Mac-Address, MN-Id (if present)
Linux API – TBD
This functional block is required for detecting the triggers related to mobile node’s attachment, detachment, address configuration and router discovery related events. The network triggers, ARP message for the default-router’s MAC address, Gratuitous ARP message, DHCP Request message, IPv6 ND messages are the potential triggers for the MAG to initiate PMIPv6 signaling. In some cases, trigger can also be based on detecting a new MAC address on the access link by other link-layer specific means. Refer to: RFC 5844, RFC 5213, RFC 4436, RFC 5227. The identity of the mobile node in these triggers is always the Mac address, except for DHCPv4, where the client-identifier option can potentially be the mobile node identifier (if set by the client or a transit node such as an access point, or a WLAN controller).
Identity Management
GET-MN-Identity. Parameters: Mac Address, MN-Id
TBD
The identity of the mobile node is tied to the access authentication. When the mobile node using 802. 1x/EAP mechanisms complete the access authentication, its identity used for authentication and the corresponding Mac address of the MN is known. If access Authenticator function and the MAG are functionally collocated on the same node, it is internal to the implementation as how that mapping between the mobile node’s identity and its link-layer/Mac identifier is obtained. It is also possible these functions are hosted on different network nodes (Ex: Authenticator on the AP and the MAG on the Wireless-LAN-controller/first-hop-router), but with some protocol interface between the two nodes, that enables the MAG to obtain the mobile node’s identity. Refer to Section 6. 6, RFC 5213. When using Mac Address as the MN-Id, the security implications and the Mac address in the policy profile needs to be understood.
Policy Profile
GET-MN-Profile. Parameters: MN-Id
The mobile’s node policy profile identifies the service preferences for a given mobile node. Parameters such as PMIPV6 Domain, LMA IP Address, 3GPP APN., are present in the profile. 2, RFC 5213 This profile is typically on a central policy store such as AAA, or it can also be locally configured. Refer to PMIPv6 RADIUS draft, or PMIPv6 Diameter Interface (RFC 5779).
PMIPv6 Signaling
PBU/PBA Messages
The options that are required in the PBU message are a. ) Home Network Prefix option b. ) IPv4 Home Address Request option c. ) Access Technology Type option d. ) Link-layer Identifier option e. ) Handoff Indicator option. Other optional parameters such as Service Selection Option for carrying the 3GPP APN information, Access Network Information option, IPv4 Traffic Offload Option, and any Vendor Specific options. Refer to Section 8 (RFC 5213). Section 3 (RFC 5844), Section 3 (RFC 5094), Section 3 (RFC 5149). The PBU is just MIPv6 BU message. Any of the MIPv6 Open source implementations can be used as the messaging library after adding the new options.
DHCPv4 Interactions
Get-IP-Address-From-LMA, Assign-IP-Address-To-MN. Parameters: MN-Id, Mac Address, IPv4 home Address, Subnet Mask, Default-router Address
Example
The mobile node obtains its IPv4 address using DHCPv4. RFC-5844 supports two modes of DHCP configurations, DHCP server collocated on the MAG and the DHCP Relay collocated on the MAG. Implementing DHCP server (minimalistic) collocation on the MAG is the simpler approach. The needed interactions are the ability to influence the DHCP server to assign an IPv4 address that the MAG obtained from LMA over PMIPv6 signaling plane. When there is DHCP Discover request from the mobile node, the DHCP server should trigger the MAG and the MAG should return the IP address after completing the PMIPv6 signaling with the mobile node’s LMA. The DHCP server should assign the IP address that it obtains from the LMA. The MAG should also be able to respond to any ARP requests for the default-router address.
Tunnel Management
Create-Tunnel, Delete Tunnel. Parameters: Encap-Type, IP Source Address, IP Destination Address
PMIPv6 specifications support GRE, IP-in-IP encapsulation modes. In other words, the tunnel encapsulations can be IPv4-GRE, IPv6-GRE, IPv4 and IPv6. The payload packet can be IPv4, or IPv6, carried with the negotiated tunnel encap. The linux open source package, IPRoute2, support both these encapsulation modes.
IP Forwarding
Add-IPv4-Tunnel-Route, Delete-IPv4-Tunnel-Route, Add-Reverse-Tunnel-Policy-Route, Delete-Reverse-Tunnel-Policy-Route. Parameters: IPv4 Address, IPv6-Prefix, Tunnel-Interface-Id, MN-MAG-Interface-Id.
The MAG should ensure any IPv4 or IPv6 packets from the mobile node using the IP addresses assigned by the LMA, should be reverse tunneled over the PMIPv6 LMA tunnel. Typically, a PBR route tied to the MAC address, source IPv4 address, source IPv6 prefix in the packet headers can be used for selecting the packet for reverse tunneling. When local-routing is enabled, there are some optimizations needed.
Local Mobility Anchor[edit]
Proxy Model
Extend open source MIPv6 Home Agent to support PMIPv6
Addressing Model
Security Model
Data Structures
Extend the BCE table with new parameters, define new PMIPv6 mobility options
Proxy Mobile IPv6 Implementations[edit]
Cisco PMIPv6[1]
Nokia Siemens Networks
Starent (now part of Cisco)
Number of other LTE PGW vendors
OpenAirInterface Proxy Mobile IPv6 (OAI PMIPv6)[2]
OPMIP – an open-source implementation of the Proxy MIPv6 mobility management protocol[3]
UMIP – Mobile IPv6 and NEMO for Linux[4]
Proxy Mobile IPv6 Specifications[edit]
Internet Standards (IETF)[edit]
S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. Patil “Proxy Mobile IPv6”, RFC 5213, August 2008
R. Wakikawa and S. Gundavelli, “IPv4 Support for Proxy Mobile IPv6”, RFC 5844, May 2010
A. Muhanna, M. Khalil, S. Gundavelli and K. Leung, “Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6”, RFC 5845, June 2010
A. Gundavelli, and K. Leung, “Binding Revocation for IPv6 Mobility”, RFC 5846, June 2010
V. Devarapalli, R. Koodli, H. Lim, N. Kant, S. Krishnan & J. Laganier, “Heartbeat Mechanism for Proxy Mobile IPv6”, RFC 5847, June 2010
S. Gundavelli, M. Townsley, O. Troan and W. Dec, “Address Mapping of IPv6 Multicast Packets on Ethernet”, RFC 6085, January 2011
T. Schmidt, M. Waehlisch, S. Krishna, “Base Deployment for Multicast Listener Support in Proxy Mobile IPv6”, RFC 6224, April 2011
J. Korhonen & V. Devarapalli, “Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6”, RFC 6097, February 2011
J. Korhonen, J. Bournelle, K. Chowdhury, A. Muhanna, U. Meyer, “MAG & LMA Interactions with Diameter Server”, RFC 5779, February 2011
V. Devarapalli, A. Patel & K. Leung, “Mobile IPv6 Vendor Specific Option”, RFC 5094, December 2007
J. Korhonen, S. Gundavelli, H. Yokota, and X. Cui, “Dynamic LMA Assignment Support in Proxy Mobile IPv6”, RFC 6463, December 2011
F. Abinader, S. Leung, S. Krishnan, and D. Premec, “Bulk Registration Support in Proxy Mobile IPv6”, RFC 6602, April 2012
F. Xia, B. Sarikaya, J. Gundavelli and D. Damic, “RADIUS Support for Proxy Mobile IPv6”, RFC 6572, April 2012
G. Keeni, K. Koide, S. Gundavelli, and R. Wakikawa, “Proxy Mobile IPv6 Management Information Base”, RFC 6475, January 2012
M. Liebsch, S. Jeong & Q. Wu, “Localized Routing Problem Statement”, RFC 6275, June 2011
S. Krishnan, R. Koodli, P. Loureiro, Q. Wu & A. Dutta, “Localized Routing for Proxy Mobile IPv6”, RFC 6705, September 2012
S. Gundavelli, X. Zhou, J. Korhonen, R. Koodli, G. Feige, “IPv4 Traffic Offload Option for Proxy Mobile IPv6 (SIPTO)” RFC 6909, April 2013
S. Gundavelli, J. Korhonen, M. Grayson, K. Leung, & R. Pazhyannur, “Access Network Information Option for PMIPv6”, RFC 6757, October 2012
X. Korhonen, C. Williams, and S. Gundavelli, “Prefix Delegation for PMIPv6”, RFC 7148 February 2014
S. Gundavelli, “Reserved IPv6 Interface Identifier for Proxy Mobile IPv6”, RFC 6543 March, 2012
M. Liebsch, P. Seite, H. Yokota, J. Korhonen & S. Gundavelli, “QoS Support for Proxy Mobile IPv6”, RFC 7222 April 2014
S. Krishnan, S. Liebsch, H. Yokota & J. Korhonen, “Update Notifications for Proxy Mobile IPv6”, RFC 7077, November 2013
R. Wakikawa, R. Pazhyannur, S. Gundavelli & C. Perkins, “Separation of Control and User Plane for Proxy Mobile IPv6”, RFC 7389, October 2014
R. Speicher, S. Korhonen & J. Kaippallimalil, “Extensions to the Proxy Mobile IPv6 (PMIPv6) ANI Option”, RFC 7563, June 2015
T. Melia & S. Gundavelli, “Logical-Interface Support for IP Hosts with Multi-Access Support”, RFC 7847, May 2016
CJ. Bernardos, “Proxy Mobile IPv6 Extensions to Support Flow Mobility”, RFC 7864, May 2016
Z. Yan, J. Lee, & X. Lee, “Home Network Prefix Renumbering in Proxy Mobile IPv6”, RFC 8191, August 2017
D. Patki, S. Lee, Q. Fu, & L. Bertz, “Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor”, RFC 8127, August 2017
P. Seite, A. Yogin, & S. Gundavelli, “MAG Multipath Binding Option”, RFC 8278, January 2018
S. Gundavelli, “Applicability of Proxy Mobile IPv6 Protocol for WLAN Access Networks”,, October 2011
M. Liebsch & S. Gundavelli, “Proxy Mobile IPv6 inter-working with WiFi Access Authentication”,, February, 2011
S. Grayson, Y. Lee, H. Deng & H. Yokota, “Multiple APN Support for Trusted Wireless LAN Access”,, March 2012
SDO Standards (3GPP, 3GPP2 & WiMAX)[edit]
3GPP SA2, “Architecture for Non-3GPP Access”, 3GPP TS 23. 402,, October 2008
3GPP CT4, “Proxy Mobile IPv6 – Stage 3 Specification”, 3GPP TS 29. 275,, June 2011
3GPP2, “Network PMIP Support”, X. S0061-0 v1. 0,, December 2008
WIMAX, “NWG PMIPv6 Stage-3 Specification”,, October 2008
See also[edit]
Mobile IP
Host Identity Protocol (HIP)
Identifier/Locator Network Protocol (ILNP)
References[edit]
^ “Proxy Mobile IPv6: Network-Based Mobility Deployment Guide – Proxy Mobile IPv6 Network-Based Mobility [Cisco IOS XE 3S]”. Cisco.
^ “Archived copy”. Archived from the original on 2013-01-14. Retrieved 2012-07-02. CS1 maint: archived copy as title (link)
^ “OPMIP – ATNoG – Aveiro Telecommunications and Networking Group (TN-AV)”.
^ “UMIP – Mobile IPv6 and NEMO Basic Support implementation for Linux”
Configuring Proxy Mobile IP – Cisco
Table Of Contents
Configuring Proxy Mobile IP
Understanding Proxy Mobile IP
Overview
Components of a Proxy Mobile IP Network
How Proxy Mobile IP Works
Agent Discovery
Subnet Map Exchange
Registration
Tunneling
Proxy Mobile IP Security
Configuration Guidelines
Configuring Proxy Mobile IP on Your Wired LAN
Configuring Proxy Mobile IP on Your Access Point
This chapter describes how to configure your access point’s proxy Mobile IP feature. This chapter contains these sections:
•Understanding Proxy Mobile IP
•Configuring Proxy Mobile IP
These sections explain how access points conduct proxy Mobile IP:
•Overview
•Components of a Proxy Mobile IP Network
•How Proxy Mobile IP Works
•Proxy Mobile IP Security
The access point’s proxy Mobile IP feature works in conjunction with the Mobile IP feature in Cisco IOS software. When you enable proxy Mobile IP on your access point and on your wired network, the access point helps client devices from other networks remain connected to their home networks. The visiting client devices do not need special software; the access point provides proxy Mobile IP services on their behalf. Any wireless client can participate.
Mobile IP provides users the freedom to roam beyond their home subnets while maintaining their home IP addresses. This enables transparent routing of IP datagrams to mobile users during their movement, so that data sessions can be initiated to them while they roam. For example, a client device with an IP address of 192. 95. 5. 2 could associate to an access point on a network whose IP addresses are in the 209. 165. 200. x range. The guest client device keeps its 192. 2 IP address, and the access point forwards its packets through a Mobile IP enabled router across the Internet to a router on the client’s home network.
Access points with proxy Mobile IP enabled attempt to provide proxy service for any client device that associates and does not perform the following:
•Does not issue a DHCP request to get a new IP address.
•Does not support a Mobile IP stack. If a device supports a Mobile IP stack, the access point assumes that the device will perform its own Mobile IP functions.
You enable proxy Mobile IP for specific SSIDs on the access point, providing support only for clients that use those SSIDs. Proxy Mobile IP does not support VLANs. You can pause proxy Mobile IP support without losing your proxy Mobile IP configuration.
Proxy Mobile IP is disabled by default.
Note Guest client devices do not receive broadcast and multicast packets.
Five devices participate in proxy Mobile IP:
•A visiting client device. The visiting client device is any device such as a personal digital assistant or a laptop that can associate to a wireless access point. It does not need any special proxy Mobile IP software.
•An access point with proxy Mobile IP enabled. The access point proxies on behalf of the visiting client device, performing all Mobile IP services for the device.
•An authoritative access point on your network supporting proxy Mobile IP. The authoritative access point uses a subnet map to keep track of the home agent information for all visiting client devices.
•A home agent. The home agent is a router on the visiting client’s home network that serves as the anchor point for communication with the access point and the visiting client. The home agent tunnels packets from a correspondent node on the Internet to the visiting client device.
•A foreign agent. The foreign agent is a router on your network that serves as the point of attachment for the visiting client device when it is on your network, delivering packets from the home agent to the visiting client.
Figure 15-1 shows the five participating devices.
Figure 15-1 Participating Devices in Proxy Mobile IP
The proxy Mobile IP process has four main phases. These sections describe each phase:
•Agent Discovery
•Subnet Map Exchange
•Registration
•Tunneling
During the agent discovery phase, the home agent and the foreign agent advertise their services on the network by using the ICMP Router Discovery Protocol (IRDP). The access point listens to these advertisements.
The IRDP advertisements carry Mobile IP extensions that specify whether an agent is a home agent, foreign agent, or both; its care-of address; the types of services it provides, such as reverse tunneling and Generic Routing Encapsulation (GRE); and the allowed registration lifetime or roaming period for visiting client devices. Rather than waiting for agent advertisements, an access point can send out an agent solicitation. This solicitation forces any agents on the network to immediately send an agent advertisement.
When an access point determines that a client device is connected to a foreign network, it acquires a care-of address for the visiting client. The care-of address is an IP address of a foreign agent that has an interface on the network being visited by a client device. An access point can share this address among many visiting client devices.
When the visiting client associates to an access point, the access point compares the client’s IP address with that of its own IP network information and detects that the client is a visitor from another network. The access point then begins the registration. However, before the access point can begin the registration process on behalf of the visiting client, it needs to know the home agent IP address of the visiting client. It gets the home agent’s IP address by looking it up on a subnet map table.
Each access point with proxy Mobile IP enabled maintains a subnet map table. The subnet map table consists of a list of home agent IP addresses and their subnet masks. Table 15-1 is an example of a subnet map table.
Table 15-1 Example of a Subnet Map Table
Home Agent
Subnet Mask
10. 10. 1
255. 255. 0
10. 4. 2
10. 3. 4
255. 248
10. 12. 1. 0. 0
Access points use the subnet map table to determine the IP address of the visiting client’s home agent. When an access point boots up or when proxy Mobile IP is first enabled on an access point, it obtains its own home agent information using the agent discovery mechanism. It sends this information to another access point called an authoritative access point (AAP). The AAP is an access point that is responsible for keeping the latest subnet map table.
When the AAP receives the new information, it replies to the access point with a copy of the latest subnet map table. The new access point now has the latest subnet map table locally and it is ready to perform proxy Mobile IP for visiting clients. Having the subnet map table locally helps the access point do a quick lookup for the home agent information. Meanwhile, the AAP adds the new access point to its list of access points and the home agent information to its subnet map table. The AAP then updates all the other access points with this additional piece of information.
You can designate up to three AAPs on your wireless LAN. If an access point fails to reach the first AAP, it tries the next configured AAP. The AAPs compare their subnet map tables periodically to make sure they have the same subnet map table. If the AAP detects that there are no more access points for a particular home agent, it sends a deregistration packet on behalf of the broadcast address of the home agent subnet to see if the home agent is still active. If the home agent responds, the AAP keeps the home agent entry in the subnet map table even though there are no access points in the home agent’s subnet. This process supports client devices that have already roamed to foreign networks. If the home agent does not respond, the AAP deletes the home agent entry from the subnet map table.
When a client device associates to an access point and the access point determines that the client is visiting from another network, the access point performs a longest-match lookup on its subnet map table and obtains the home agent address for the visiting client. When the access point has the home agent address, it can proceed to the registration step.
The access point is configured with the mobility security association (which includes the shared key) of all potential visiting clients with their corresponding home agents. You can enter the mobility security association information locally on the access point or on a RADIUS server on your network, and access points with proxy Mobile IP enabled can access it there.
The access point uses the security association information, the visiting client’s IP address, and the information that it learns from the foreign agent advertisements to form a Mobile IP registration request on behalf of the visiting client. It sends the registration request to the visiting client’s home agent through the foreign agent. The foreign agent checks the validity of the registration request, which includes checking that the requested lifetime does not exceed its limitations and that the requested tunnel encapsulation is available. If the registration request is valid, the foreign agent relays the request to the home agent.
The home agent checks the validity of the registration request, which includes authentication of the visiting client. If the registration request is valid, the home agent creates a mobility binding (an association of the visiting client with its care-of address), a tunnel to the care-of address, and a routing entry for forwarding packets to the home address through the tunnel.
The home agent then sends a registration reply to the visiting client through the foreign agent (because the registration request was received through the foreign agent). The foreign agent checks the validity of the registration reply, including ensuring that an associated registration request exists in its pending list. If the registration reply is valid, the foreign agent adds the visiting client to its visitor list, establishes a tunnel to the home agent, and creates a routing entry for forwarding packets to the home address. It then relays the registration reply to the visiting client.
Finally, the access point checks the validity of the registration reply. If the registration reply specifies that the registration is accepted, the access point is able to confirm that the mobility agents are aware of the visiting client’s roaming. Subsequently, the access point intercepts all packets from the visiting client and sends them to the foreign agent.
The access point re-registers on behalf of the visiting client before its registration lifetime expires. The home agent and foreign agent update their mobility binding and visitor entry, respectively, during re-registration.
A successful Mobile IP registration by the access point on behalf of the visiting client sets up the routing mechanism for transporting packets to and from the visiting client as it roams.
The visiting client sends packets using its home IP address, effectively maintaining the appearance that it is always on its home network. Even while the visiting client is roaming on foreign networks, its movements are transparent to correspondent nodes (other devices with which the visiting client communicates).
Data packets addressed to the visiting client are routed to its home network, where the home agent intercepts and tunnels them to the care-of address toward the visiting client. Tunneling has two primary functions: encapsulation of the data packet to reach the tunnel endpoint, and decapsulation when the packet is delivered at that endpoint. The tunnel mode that the access point supports is IPinIP Encapsulation.
Typically, the visiting client sends packets as it normally would. The access point intercepts these packets and sends them to the foreign agent, which routes them to their final destination, the correspondent node.
GRE Encapsulation
Instead of IPinIP Encapsulation, you can select GRE encapsulation. Use the ip proxy-mobile tunnel gre command to select GRE encapsulation.
Reverse Tunnels
Forward tunnels carry packets destined to the mobile node from the home network to the foreign network. You can also set up a reverse tunnel. A reverse tunnel carries packets between the home network and the foreign network, but it tunnels packets from the mobile node instead of packets to the mobile node. Therefore, instead of the foreign agent routing the packets from the mobile node normally, the foreign agent sends packets from the mobile node back to the home agent through the reverse tunnel. The home agent on the mobile node’s home subnet routes the packets normally. Use the ip proxy-mobile tunnel reverse command to configure a reverse tunnel.
Mobile IP uses a strong authentication scheme to protect communications to and from visiting clients. All registration messages between a visiting client and the home agent must contain the Mobile-Home Authentication Extension (MHAE). Proxy Mobile IP also implements this requirement in the registration messages sent by the access point on behalf of the visiting clients to the home agent.
The integrity of the registration messages is protected by a shared 128-bit key between the access point (on behalf of the visiting client) and the home agent. You can enter the shared key on the access point or on a RADIUS server.
The keyed message digest algorithm 5 (MD5) in prefix+suffix mode is used to compute the authenticator value in the appended MHAE. Mobile IP and proxy Mobile IP also support the hash-based message authentication code (HMAC-MD5). The receiver compares the authenticator value it computes over the message with the value in the extension to verify the authenticity.
Optionally, the MHEA and the Foreign-Home Authentication Extension are appended to protect message exchanges between a visiting client and foreign agent and between a foreign agent and home agent, respectively.
Replay protection uses the identification field in the registration messages as a timestamp and sequence number. The home agent returns its time stamp to synchronize the visiting client for registration. In proxy Mobile IP, the visiting clients are not synchronized to their home agents because the access point intercepts all home agent messages.
These sections describe how to configure proxy Mobile IP:
•Configuration Guidelines
•Configuring Proxy Mobile IP on Your Wired LAN
•Configuring Proxy Mobile IP on Your Access Point
Before configuring proxy Mobile IP, you should consider these guidelines:
•You can enable proxy Mobile IP only on root access points (units connected to the wired LAN). You cannot enable proxy Mobile IP on repeater access points.
•Access points participating in proxy Mobile IP should be configured with gateway addresses. You can configure the gateways manually, or the access points can receive gateways through DHCP.
•The foreign and home agents must reside on the network gateways where you want to support proxy Mobile IP.
•If your authoritative access points receive their IP addresses through DHCP, use the access point host names to specify the AAPs in the proxy Mobile IP configuration.
•Proxy Mobile IP does not support broadcast and multicast traffic for visiting clients.
•To use proxy Mobile IP with DHCP-enabled client devices, you must disable Media Sense on the client devices. You can find instructions for disabling Media Sense in Microsoft Knowledge Base Article Q239924. Click this URL to browse to this article:
•Proxy Mobile IP does not support VLANs.
•If you disable proxy Mobile IP on your access point, the entire proxy Mobile IP configuration is cleared. To disable proxy Mobile IP without clearing the configuration, use the ip proxy-mobile pause command.
Proxy Mobile IP on access points works in conjunction with Mobile IP configured on your network routers.
Note To avoid problems with roaming client devices, you must configure two hidden global configuration mode commands on your Mobile IP router: ip mobile bindupdate and ip mobile bindupdate ack.
Beginning in privileged EXEC mode, follow these steps to configure proxy Mobile IP on your access point:
Command
Purpose
Step 1
configure terminal
Enter global configuration mode.
Step 2
ip proxy-mobile enable
Enable proxy Mobile IP on the access point.
Step 3
ip proxy-mobile aap ip-address[ip-address] [ip-address]
Designate the access points that serve as the authoritative access points (the access points with which this access point compares its subnet table). Note You should specify at least two access points as AAPs in case one AAP fails. If you designate only one AAP and it goes offline, you lose all the information in the subnet map table.
Step 4
ip proxy-mobile secure node address-start address-endspi spi key { hex | ascii} key
Create security association settings for an IP address or for a range of IP addresses. •Enter an IP address, or the starting and ending addresses in an IP range. •Enter the security parameter index. •Enter a key for the security parameter. Specify whether the key contains hexadecimal or ASCII characters. If you choose hexadecimal, the key must contain 32 characters. If you choose ASCII, the key can contain up to 16 characters with no minimum length.
Step 5
interface fastethernet 0
Enter interface configuration mode for the Ethernet port.
Step 6
ip proxy-mobile
Enable proxy Mobile IP on the Ethernet port.
Step 7
exit
Return to global config mode.
Step 8
interface dot11radio { 0 | 1}
Enter interface configuration mode for the radio port. The 2. 4-GHz radio is radio 0, and the 5-GHz radio is radio 1. Will be different in other products. Research.
Step 9
Enable proxy Mobile IP on the radio port.
Step 10
ssid ssid
Enter an SSID for which you want to enable proxy Mobile IP. Note Proxy Mobile IP functionality is not supported on SSIDs where VLAN is also enabled.
Step 11
Enable proxy Mobile IP for the SSID.
Step 12
Step 13
interface bvi1
Enter interface configuration mode for the bridge virtual interface (BVI).
Step 14
Enable proxy Mobile IP on the BVI.
Step 15
end
Return to privileged EXEC mode.
Step 16
copy running-config startup-config
(Optional) Save your entries in the configuration file.
Use the no form of the ip proxy-mobile commands to disable proxy Mobile IP. Use the ip proxy-mobile pause command to disable proxy Mobile IP without losing your proxy Mobile IP configuration.
This example shows how to enable proxy Mobile IP on an access point for the SSID tsunami for IP addresses from 10. 91. 7. 151 to 10. 176:
ap1200# configure terminal
ap1200(config)# ip proxy-mobile enable
ap1200(config)# ip proxy-mobile aap 192. 168. 15. 22 192. 24 192. 28
ap1200(config)# ip proxy-mobile secure node 10. 151 10. 176 spi 102 key ascii
0987654
ap1200(config)# interface fastethernet 0
ap1200(config-if)# ip proxy-mobile
ap1200(config-if)# interface dot11radio 0
ap1200(config-if)# ssid tsunami
ap1200(config-if-ssid)# ip proxy-mobile
ap1200(config-if-ssid)# exit
ap1200(config)# interface bvi1
ap1200(config-if-ssid)# end
Mobile IP and TCP/IP Address Resolution Protocol (ARP …
Please Whitelist This Site?
I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don’t want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. 🙂
If you like The TCP/IP Guide, please consider the download version. It’s priced very economically and you can read all of it in a convenient format without ads.
If you want to use this site for free, I’d be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select “Disable on “. Or go to the Tools menu and select “Adblock Plus Preferences… “. Then click “Add Filter… ” at the bottom, and add this string: “@@||^$document”. Then just click OK.
Thanks for your understanding!
Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide
NOTE: Using software to mass-download the site degrades the server and is you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.
Custom Search
Mobile IP and TCP/IP Address Resolution Protocol (ARP) Operation
(Page 2 of 2)
Additional Home Agent Tasks To Deal With ARP
Solving this problem requires the
intervention of, you guessed it, the home agent. It must perform two
tasks to enable local hosts to send to the mobile node:
ARP Proxying: The home agent must listen
for any ARP Requests sent by nodes on the same network as any
of the mobile nodes that are currently registered to it. When it hears
one, it replies in the mobile node’s stead, and specifies its
own data link layer address as the binding for the mobile node’s
IP address. This will cause hosts on the home network to send any datagrams
intended for the mobile node to the home agent where they can be forwarded.
This process is illustrated in Figure 135.
“Gratuitous” ARP: Proxying helps
with ARP Requests but what about devices that already have cache
entries for the mobile node? As soon as the mobile node leaves the network,
these become automatically stale. To correct them, the home agent sends
what is called a gratuitous ARP message that tells devices on
the local network to associate the mobile node’s IP address with the
home agent’s data link layer address. The term “gratuitous”
refers to the fact that the message isn’t being sent in order to perform
an actual address resolution but merely to cause caches to be updated.
It may be sent more than once to ensure that every device “gets
the message”.
Figure 135: ARP Proxying By Mobile IP Home AgentThe home agent must take special steps to deal with transmissions from devices on the local network to the mobile node. In this example (using short hardware addresses for simplicity) the hardware address of the mobile node is #48 and that of the home agent #63. A local client on the home network with hardware address #97 sends an ARP Request to find out the hardware address of the mobile node. The home agent responds on the mobile’s behalf, specifying not hardware address #48 but rather its own, #63. The client will thus send to the home agent, which can then forward the data to the mobile node on the foreign network.
Once this is done, ARP should function
normally on the home link. Of course, when the mobile device returns
back to the home network, the process must be reversed. Upon deregistration
with the home agent, it will stop proxying for the mobile node. Both
the mobile node and the home agent will also send gratuitous ARP broadcasts
that update local device caches to again associate the mobile node’s
IP address with its own layer two address, instead of that of the home
agent.
Key Concept: To avoid problems with hosts on the mobile node’s home network trying to send datagrams to it at layer two, the home agent is required to use proxy ARP to direct such devices to send to the home agent so they can be forwarded. It must also use “gratuitous” ARP to update any existing ARP caches to that effect.
If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money! ) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!
Home –
Table Of Contents – Contact Us
The TCP/IP Guide ()
Version 3. 0 – Version Date: September 20, 2005
� Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.