Proxy Mobile IPv6

This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages) This article includes a list of references, related reading, or external links, but its sources remain unclear because it lacks inline citations. Please help improve this article by introducing more precise citations. (December 2017) (Learn how and when to remove this message) This article relies excessively on references to primary sources. Please improve this article by adding secondary or tertiary sources. Find sources: "Proxy Mobile IPv6" – news · newspapers · books · scholar · JSTOR (December 2017) (Learn how and when to remove this message) (Learn how and when to remove this message)

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.

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.

               +--------+       _----_                 |                +--------+       _----_
               |        |     _(      )_               |                |        |     _(      )_
               |        |----( 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
                                                       |

• 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

The PMIPv6 architecture defines following functional entities:

• Local Mobility Anchor (LMA)
• Mobile Access Gateway (MAG)
• Mobile Node (MN)
• Correspondent Node (CN)

1. A mobile host enters a PMIP domain
2. A Mobile Access Gateway on that link checks host authorization
3. A mobile host obtains an IP address
4. A Mobile Access Gateway updates a Local Mobility Anchor about the current location of a host
5. Both MAG and LMA create a bi-directional tunnel
6. A Mobile Access Gateway sends a Router Advertise message to MN with Care-of-Address

• Access authentication and mobile node's identity
• Mobile node's policy profile
• MAG and Authenticator Collocation

• Control Plane Security
• Data Plane Security

• IPv4 Address Assignment over DHCPv4
• Stateless Autoconf for IPv6

• 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

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.

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	TBD	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 ..etc., are present in the profile. Refer to Section 6.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	TBD	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	Example	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.	TBD	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.

Functional Block	Requirement	Platform API	Description
Proxy Model	TBD	TBD	Extend open source MIPv6 Home Agent to support PMIPv6
Addressing Model	TBD	TBD	TBD
Security Model	TBD	TBD	TBD
Data Structures	TBD	TBD	Extend the BCE table with new parameters, define new PMIPv6 mobility options

• 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]

• 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. Muhanna, M. Khalil, S. 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. Gundavelli, K. Leung, S. Krishnan, and D. Premec, "Bulk Registration Support in Proxy Mobile IPv6", RFC 6602, April 2012
• F. Xia, B. Sarikaya, J. Korhonen, S. 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. Zhou, J. 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. Gundavelli, M. 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. Pazhyannur, S. Speicher, S. Gundavelli, J. 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. Gundavelli, J. 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", http://tools.ietf.org/html/draft-gundavelli-netext-pmipv6-wlan-applicability, October 2011
• M. Liebsch & S. Gundavelli, "Proxy Mobile IPv6 inter-working with WiFi Access Authentication", http://tools.ietf.org/html/draft-liebsch-netext-pmip6-authiwk, February, 2011
• S. Gundavelli, M. Grayson, Y. Lee, H. Deng & H. Yokota, "Multiple APN Support for Trusted Wireless LAN Access", http://tools.ietf.org/html/draft-gundavelli-netext-multiple-apn-pmipv6, March 2012

• 3GPP SA2, "Architecture for Non-3GPP Access", 3GPP TS 23.402, http://www.3gpp.org/ftp/Specs/archive/23_series/23.402, October 2008
• 3GPP CT4, "Proxy Mobile IPv6 - Stage 3 Specification", 3GPP TS 29.275, http://www.3gpp.org/ftp/Specs/archive/29_series/29.275/29275-a20.zip, June 2011
• 3GPP2, "Network PMIP Support", X.S0061-0 v1.0, http://www.3gpp2.org/Public_html/specs/X.S0061-0_v1.0_081209.pdf, December 2008
• WIMAX, "NWG PMIPv6 Stage-3 Specification", http://members.wimaxforum.org/apps/org/workgroup/nwg/download.php/38973/01085_r000_NWG_R1.5_PMIPv6_Stage3_Specification_D1.zip, October 2008

• Mobile IP
• Host Identity Protocol (HIP)
• Identifier-Locator Network Protocol (ILNP)