RFC 5563
WiMAX Forum / 3GPP2 Proxy Mobile IPv4
RFC 5563: WiMAX Forum / 3GPP2 Proxy Mobile IPv4 🎀
okay bestie, let's talk about RFC 5563, titled "WiMAX Forum / 3GPP2 Proxy Mobile IPv4" 💖 It's an Independent Submission, which means it came in from outside the usual IETF stream, and it's marked as Informational, so it's not a standards-track spec. It was written by K. Leung, G. Dommety, P. Yegani, and K. Chowdhury, with Leung and Dommety from Cisco Systems, Yegani from Juniper Networks, and Chowdhury from Starent Networks. It's dated February 2010 and has ISSN 2070-1721. The header doesn't list any RFCs it obsoletes or updates, so it's a standalone doc 🦋
Abstract 🌸
Mobile IPv4 is a standard mobility protocol that lets an IPv4 device move between networks while keeping its IP address ✨ The mobile device runs the Mobile IPv4 client function to tell its routing anchor, the Home Agent, where it is. The issue is that lots of IPv4 devices can't do that, for all sorts of reasons 💀
So this doc describes Proxy Mobile IPv4 (PMIPv4) 🧚 The idea is to put the Mobile IPv4 client function inside a network entity, so an unaltered device that has no idea it's mobile still gets mobility support. The doc also covers one specific use of PMIPv4 from the WiMAX Forum, plus another application that's going to be adopted in 3GPP2 🔥
Status of This Memo 📜
This is not an Internet Standards Track spec. It's published just for information 💅
It's a contribution to the RFC Series, separate from any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about how valuable it is to implement or deploy 🫶 Docs the RFC Editor approves aren't candidates for any level of Internet Standard, see Section 2 of RFC 5741 ✨
For the current status, errata, and a way to send feedback, check http://www.rfc-editor.org/info/rfc5563 🌈
Copyright Notice 💜
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved 🎀
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 🙈
Table of Contents 🧚
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Benefits of Proxy Mobile IPv4 ...................................6
4. Overview of Proxy Mobile IPv4 ...................................7
4.1. Mobility Signaling for Mobile Device .......................7
4.1.1. Proxy Registration during Initial Network
Attachment ..........................................8
4.1.2. Proxy Registration Renewal .........................11
4.1.3. Proxy Handover Support .............................12
4.1.4. Resource Cleanup ...................................13
4.2. Establishment of a Bi-Directional Tunnel ..................14
4.2.1. Packet Forwarding ..................................14
4.2.2. Broadcast and Multicast ............................14
4.2.3. Forwarding between Devices on the Same PMA .........15
4.3. Security Association between the PMA and the HA ...........15
4.4. Registration Sequencing ...................................15
4.5. Mobile Device Interface Configuration .....................16
4.6. Dynamic HA Discovery ......................................16
5. Proxy Mobile IPv4 Extensions ...................................16
5.1. PMIPv4 Per-Node Authentication Method Extension ...........17
5.2. Proxy Mobile IPv4 Interface ID Extension ..................18
5.3. Proxy Mobile IPv4 Device ID Extension .....................18
5.4. Proxy Mobile IPv4 Subscriber ID Extension .................19
5.5. PMIPv4 Access Technology Type Extension ...................20
6. Appearance of Being at Home Network ............................22
6.1. ARP Considerations ........................................22
6.2. ICMP Considerations .......................................23
6.3. DHCP Considerations .......................................23
6.4. PPP IPCP Considerations ...................................24
6.5. Link-Local Multicast and Broadcast Considerations .........24
7. Proxy Mobility Agent Operation .................................24
8. Home Agent Operation ...........................................25
8.1. Processing Proxy Registration Requests ....................26
9. Mobile Device Operation ........................................26
9.1. Initial Network Access ....................................27
9.2. Mobile Device Mobility ....................................27
9.3. Sending and Receiving Packets .............................27
10. Proxy Mobile IPv4 Use Case in WiMAX ...........................28
10.1. Proxy Mobile IPv4 Call Flow Examples with Split
PMA in WiMAX .............................................31
11. Proxy Mobile IPv4 Use Case in 3GPP2 ...........................33
11.1. Handover Considerations in 3GPP2 .........................36
12. IANA Considerations ...........................................37
12.1. Mobile IPv4 Extension Types ..............................38
12.2. Mobile IPv4 Error Codes ..................................38
13. Security Considerations .......................................38
14. Acknowledgements ..............................................38
15. References ....................................................39
15.1. Normative References .....................................39
15.2. Informative References ...................................391. Introduction ✨
There are loads of IPv4 devices that don't have Mobile IPv4 [RFC3344] functionality, and can't be upgraded to have it. But they still need mobility, bestie 😭 Proxy Mobile IPv4 gives them mobility support without "touching" the devices at all 🦋
The scheme works through network entities that handle mobility management for a mobile device. The network element on the access network, called the Proxy Mobility Agent (PMA), tells the network entity on the home network, called the Home Agent (HA), where the device is. The HA is the one tied to the IPv4 address the device is using. The PMA and HA send Mobile IPv4 messages, and they correspond to the RFC 3344 entities Mobile Node (in proxy mode) and Home Agent, respectively 💅
Here are some examples of Proxy Mobile IPv4:
- A Wireless Local Area Network (WLAN) access point or cellular base station registers with the Home Agent when a mobile device associates on the air-link 📡
- An access router or Foreign Agent registers with the Home Agent when a mobile device is detected on the network 🌸
Mobile IPv4 is the protocol the network entities use because it already has what's needed to set up the route and tunneling endpoints for the mobile device's IP address. It can also deliver config parameters, like DNS server addresses and the default gateway, so the device's IP stack can work 🔥 When Mobile IPv4 is used like this, the security association is between the PMA and the HA, since those are the signaling endpoints. And when the mobile device moves to a new PMA, the HA has to handle the sequencing of messages coming from multiple PMAs, properly 👑
This doc explains how the PMA and HA give mobility management to the mobile device. It covers the generic Proxy Mobile IPv4 functionality, plus the specifics for WiMAX (Section 10) and 3GPP2 (Section 11) 🎀
Quick side note: Proxy Mobile IPv6 [RFC5213] is an IETF standard for network-based mobility management. It gives a host IP mobility without the host having to take part in any mobility-related signaling 🧚
2. Conventions Used in This Document 💅
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in RFC 2119 [RFC2119] 🌈
This doc introduces some new terminology and abbreviations. All other general mobility terms come from the Mobile IPv4 spec [RFC3344] 💜
Mobile Device 📱
The mobile device means an IPv4 device whose mobility is provided by the network. The mobile device is not required to take part in any mobility-related signaling to get mobility for an IP address it's been given 🙈
Proxy Mobile IPv4 Client (PMIPv4 Client) 🦋
This network function starts and keeps up the Proxy Mobile IPv4 registration on behalf of the mobile device. Basically, it does the Mobile IPv4 client job, but it lives in the network. Sometimes it's collocated with the Foreign Agent, and sometimes it isn't. Either way, Proxy Mobile IPv4 registration still goes via the Foreign Agent for all practical purposes, even when it's internal to the node ✨
Home Agent (HA) 🏠
The Home Agent defined in Mobile IPv4 [RFC3344] is used in the Proxy Mobile IPv4 scheme. It's the topological anchor point for the mobile device's home network, and it's the entity that manages the mobile device's reachability state. This doc defines the extra capabilities the Home Agent needs to support Proxy Mobile IPv4 💖
Foreign Agent (FA) 🌸
The Foreign Agent defined in [RFC3344] is used in the Proxy Mobile IPv4 scheme. It's either collocated with the PMIPv4 client or separate from it. From the Proxy Mobile IPv4 point of view, it serves as the tunnel endpoint 🫶
Access Router (AR) 🛜
Access Router is a commonly used term for the node in the network that connects hosts to the IP network 💅
Proxy Mobility Agent (PMA) 👑
The Proxy Mobility Agent is the logical entity in the network that covers both the PMIPv4 client and the FA functions. When the PMIPv4 client and the FA are collocated in the Access Router, you've got an integrated PMA. When they aren't collocated in the Access Router, it's called a split PMA. A PMIPv4 client can be associated with multiple FAs, and the other way around too 🔥
Proxy Registration Request (PRRQ) 📨
The Registration Request message is sent by the Proxy Mobility Agent to the Home Agent to set up a mobility binding entry for a mobile device. The message format is identical to the Mobile IPv4 Registration Request. The Proxy Mobile IPv4 extensions defined in this doc may be included for enhanced features of network-based mobility management 🧚
Proxy Registration Reply (PRRP) 📬
The Registration Reply message is sent by the Home Agent in response to a Proxy Registration Request from the Proxy Mobility Agent. The message format is identical to the Mobile IPv4 Registration Reply. The Proxy Mobile IPv4 extensions defined in this doc may be included for enhanced features of network-based mobility management 🌈
3. Benefits of Proxy Mobile IPv4 ✨
okay bestie, let's talk about why PMIPv4 is so iconic 💖 It's designed to hit the requirements listed below, and while this spec and Proxy Mobile IPv4 aren't standards themselves, they're built on a standard: Mobile IPv4 🦋 Mobile IPv4 implementations can be re-used, so a client-based mobility protocol can be used "as-is" to support network-based mobility. The new PMIPv4 extensions added to Mobile IPv4 make the whole solution more flexible 💅 The practical glow-up of having one common mobility protocol for both client-based and network-based mobility is that a Home Agent can anchor all types of mobile devices, both the ones that have the Mobile IPv4 function and the ones that lack it 🫶
The network-based mobility management solution defined in this document has the following significant reasons for its use in any wireless network:
- Support for Unmodified Hosts
An overwhelming majority of IPv4 hosts don't have Mobile IPv4 capability, and that's where PMIPv4 comes in 🌸 Providing mobility for them is achievable using Proxy Mobile IPv4, without "touching" the user's devices, across a myriad of operating systems and networking stacks. No cap, that's the whole point 💜
- Re-Use of Existing Home Agent
An existing Home Agent implementation can be used for network-based mobility too 🍓 Further enhancements are optional and only incremental in nature. There are lots of commonalities between client-based and network-based mobility, and sharing the same protocol is a significant benefit. Lowkey the best part 👑
- Reduction of Air-Link Resource Consumption
Mobility-related signaling over the air-link is eliminated 🌈 Gone. Not even a little bit 🙈
- Support for Heterogeneous Wireless Link Technologies
Since Proxy Mobile IPv4 is based on an access, technology-independent, mobility protocol, it can be used for any type of access network 🧚
From the network perspective, a mobile device is identified by the Network Access Identifier (NAI), and the forwarding is set up between the PMA and HA for the mobile device's current point of attachment on the network. The mobile device may be attached to multiple networks concurrently, although the network treats each access interface independently 🦋 This feature can be supported with the use of the PMIPv4 Access Technology Type Extension (Section 5.5) ✨
- Support for IPv4 and IPv6 Hosts
As IPv6 gets more popular, the host will likely be dual stack 💅 Adding IPv6 support to the host for Proxy Mobile IPv4 involves the methods defined in [RFC5454]. There are additional enhancements needed, which are described in "Proxy Mobile IPv6" [RFC5213]. However, support for an IPv6 host is out of the scope of this document 🥺 That's a different story for a different day, bestie.
4. Overview of Proxy Mobile IPv4 🎀
4.1. Mobility Signaling for Mobile Device
After the mobile device completes network-access authentication, the PMA exchanges Proxy Mobile IPv4 registration messages with the HA to set up proper routing and tunneling of packets from/to the Mobile Node 🚀 The PMIPv4 client is responsible for initiating the Proxy Mobile IPv4 registration. For integrated PMA, the PMIPv4 client and the FA interaction is all within the node. In the case of split PMA implementation, the interactions between the PMIPv4 client and the FA are exposed. The interface between the PMIP Client and the FA in the split PMA scenario is defined in a standards organization specification [NWG], so it's consequently out of the scope of this document 📚
The following call flows describe the operations of Proxy Mobile IPv4. The initial network attachment, registration renewal, and resource cleanup procedures are covered. Note that the protocols that interact with Proxy Mobile IP are identified and explained in more detail 🔍 The PPP/IPCP (IP Control Protocol) protocol involves a PPP client in the mobile device and a Network Access Server (NAS) in the AR. DHCP involves a DHCP client in the MN and a DHCP server in either the AR or the HA. PMIPv4 involves a PMA in the AR and an HA in the router on the home network. The Authentication, Authorization, and Accounting (AAA) protocol involves a AAA client in the AR and a AAA server in the network. The collocation of the functional entities in the AR/HA enables parameters to be shared/processed among the protocols 💜
When the various network entities are not collocated, any sharing of parameters or other state information between them is out of the scope of this document 🫶
4.1.1. Proxy Registration during Initial Network Attachment
okay so this is the first-time setup, and it's giving main character energy 💖 Here's the picture first:
+----+ +-------+ +-------+ +-----+
| | | AR / | | | | |
| MN | | PMA | | AAA | | HA |
| | | | | | | |
+----+ +-------+ +-------+ +-----+
| | | |
| 1a | 1b | |
Authentication |<------------->|<----------->| |
| | | |
| 2 | | |
+-> |-------------->| | |
| | | 3 | |
| | |-------------------------->| <-+
Address | | | | | |PMIP
Acquisition| | | 4 | | |
| | |<--------------------------| <-+
| | 5 | | |
+-> |<--------------| | |
| | | |
| 6 | | |
Data Forwarding |<------------->|<=========================>|
| | | |
Figure 1: Network Connection SetupSo the whole attachment happens in three phases 🧚. First, authentication and authorization happen when the mobile device shows up on the network. Then the mobile device asks for an IP address, and that request is what kicks off Proxy Mobile IP. PMIP is the part that assigns or authorizes the address and sets up forwarding between the PMA and the HA 🔥. The host configuration parameters may ride along in the PMIPv4 signaling too. Finally, the mobile device configures its IP stack with the address and the host configuration it got. And the vibe throughout is that packets to and from the mobile device go through both the PMA and the HA, which is very much a two-friend-group situation 🫶.
Let's go step by step, bestie 💅
1a. The mobile device sets up an L2 (Layer 2) link with the base station (not shown in the diagram) and does access authentication and authorization with the AR (Access Router). In this phase the mobile device might use the Challenge Handshake Authentication Protocol (CHAP) [RFC1994] if PPP [RFC1661] is in use, or the Extensible Authentication Protocol (EAP) [RFC3748] over foo. (Here foo is just a stand-in for the specific access technology, or PANA [RFC4058].) The AR acts as the NAS (Network Access Server) in this step 🎀.
1b. The AAA client talks to the AAA infrastructure to authenticate and authorize the mobile device. As part of this, the AAA server might download some info about the device, like the user's profile, the handset type, the assigned Home Agent address, and other capabilities of the device 🌸.
- The mobile device asks for an IP address using PPP/IPCP [RFC1332] or DHCP [RFC2131]. For PPP, the PPP client sends an IPCP Configure-Request to the NAS. For DHCP, the DHCP client sends a DHCP Discover message to the DHCP relay agent or server 🦋.
For the DHCP case, the DHCP server or DHCP relay agent sends the DHCP Ack message to the DHCP client only after PMIPv4 signaling has finished ⭐.
- Triggered by step 2, the PMA sends a Proxy Registration Request (PRRQ) to the HA. The HA's IP address comes either from the AAA server in step 1b or from some other discovery method. The PRRQ carries the Care-of Address (CoA) of the PMA, which is the collocated FA in this case. The Home Address field is set to zero, or the IP address is included as a hint in the DHCP or IPCP message.
The PRRQ MUST be protected by the methods described in the Security Considerations (Section 13) of this document. Not optional, not a suggestion, it's a MUST 🚨💀
The derivation and distribution of the MN-HA or FA-HA key is outside the scope of this document, so we're not getting into that here 🙈.
- The Home Agent sets up the mobility binding entry for the mobile device after it either assigns an IP address or authorizes the requested Home Address. The HA might also assign a Generic Routing Encapsulation (GRE) key during this step, but only if GRE tunneling is used between the PMA and HA. The HA sends back the Home Address and the GRE key (if applicable) in the Proxy Registration Reply (PRRP) to the PMA. If the requested Home Address is not authorized, the HA denies the registration with error code 129 (administratively prohibited) 😭. Once the PMA has processed the PRRP, the forwarding path for the Home Address between the PMA and HA is set up. A GRE tunnel may be used between the PMA and the HA [MIP4GREKEY]. And that's it, this event wraps up the Proxy Mobile IPv4 signaling for initial network attachment 🎉.
- After the Proxy Mobile IPv4 registration exchange, the AR gives the IP address to the mobile device in response to step 2. For IPCP, the NAS replies to the PPP client with an IPCP Configure-Nak. That reply includes the PMIPv4-assigned Home Address in the IP address configuration option, and the DNS server address in the IPCP configuration option ✨.
If the DHCP server lives on the AR, here's the flow. The DHCP server sends a DHCP Offer with the PMIPv4-assigned Home Address in the yiaddr field to the DHCP client. The DHCP client sends a DHCP Request to the DHCP server, which replies with a DHCP Ack. The host configuration (like the DNS server address) comes along in the DHCP options. Note that the DHCP messages go directly between the DHCP client and the DHCP server 🫶.
Now, when the AR is acting as a DHCP relay agent, the DHCP Discover gets relayed to the DHCP server on the HA. The DHCP server sends a DHCP Offer with the PMIPv4-assigned Home Address in the yiaddr field to the DHCP relay agent, which forwards it to the DHCP client. The DHCP Request and DHCP Ack messages get exchanged between the DHCP client and DHCP server through the relay agent 🧚. No matter what order the PMIPv4 signaling and the DHCP exchanges happen in, the same IP address ends up in the Home Address field and the yiaddr field, respectively. That's the consistency thing, and it's iconic 💜.
- At this step the mobile device's IP stack is configured with an IP address that has a forwarding path between the AR/PMA and HA. The host configuration (like DNS servers) gets set up at this point too. Now that the IPCP or DHCP procedure is finished, the mobile device is ready to send and receive IP packets 🌈. If DHCP is in use, the DHCP client renews the IP address by sending a DHCP Request straight to the DHCP server. The lease for the IP address is extended when the DHCP client gets a DHCP Ack from the DHCP server 🍓.
4.1.2. Proxy Registration Renewal
This one's the upkeep routine, and it's giving consistent 💅. Here's the picture:
+----+ +-------+ +-----+
| | | AR / | | |
| MN | | PMA | | HA |
| | | | | |
+----+ +-------+ +-----+
| | |
| | 1 |
| |----------------------->|
PMIPv4 | | |
Renewal | | 2 |
| |<-----------------------|
| | |
| | |
Figure 2: Network Connection MaintenanceBasically, as long as the mobile device stays attached to the AR, the Proxy Mobile IPv4 session stays alive through re-registration exchanges between the AR and HA 🦋.
- Before the PMIPv4 registration lifetime runs out, and as long as the AR hasn't heard anything saying the mobile device left the network, the PMA sends a PRRQ to the HA to extend the mobility binding of the mobile device 🌸. This PRRQ looks a lot like the initial one: the HA field is set to the assigned HA, and the CoA field is set to the PMA. The difference is that the Home Address field is always set to the mobile device's assigned IP address. Meanwhile, the mobile device's IP stack keeps sending and receiving IP packets using the Home Address anchored at the HA, so nothing drops for the user 💖.
- The HA sends the PRRP back in response to the PRRQ it got from the PMA. After the PMA processes that PRRP, the forwarding path between the AR and HA stays intact ✨.
4.1.3. Proxy Handover Support 🦋
okay so this is the part where the mobile device hops to a new AR and the whole thing has to stay seamless 🫶 here's the picture:
+----+ +-------+ +-------+ +-----+
| | | New | | Old | | |
| MN | | AR / | | AR / | | HA |
| | | PMA | | PMA | | |
+----+ +-------+ +-------+ +-----+
| | | |
| 1 | | |
Authentication |<------------->| | |
| | | |
| | 2 | |
+-> | |-------------------------->|
PMIPv4 | | | | |
| | | 3 | |
+-> | |<--------------------------|
| | | |
| 4 | | |
Data Forwarding |<------------->|<=========================>|
| | | |
Figure 3: AR Handoverthe AR handover is giving three phases ✨ first, authentication and authorization happen when the mobile device attaches to the new AR. once that succeeds, it triggers the Proxy Mobile IPv4 signaling. the last phase sets up the forwarding path between the new AR and HA, so the mobile device can keep sending and receiving IP packets with the same Home Address, which is still anchored at the HA 💖 here's the play-by-play:
- the mobile device sets up its L2 link with the base station (not shown) and does access authentication/authorization with the new AR, using the security method for network re-attachment 🔐
- once that authentication succeeds, the PMA sends a PRRQ to the HA 📨 the HA's IP address is usually obtained or already known through the method used for fast re-authentication during AR handover (for example, context transfer between the two ARs), though other methods may be used. the PRRQ carries the CoA of the new PMA. the Home Address field is set to zero or to the assigned IP address of the mobile device. the IP address gets obtained or known through that same method I just mentioned 🌸
- the HA updates the existing mobility binding entry for the mobile device when it processes the PRRQ. then it sends back the Home Address, pulled from the binding, in the PRRP to the new PMA. once the PMA processes that PRRP, the forwarding path for the Home Address between the new AR and HA is up and running 🎉 this event wraps up the Proxy Mobile IPv4 signaling for AR handover, periodt 💅
- this step happens around the same time as step 2. the mobile device's IP stack might notice the L2 link going down and back up after access re-authentication, and it may try to check its IP address connectivity. see Sections 6.1, 6.2, and 6.3 of this document for the considerations on ARP [RFCARP], ICMP [RFCICMP], and DHCP [RFC2131], respectively 🧚 since the forwarding path is set up between the new PMA and HA, the mobile device can receive or send IP packets using the Home Address, and that's the main character moment 👑
4.1.4. Resource Cleanup 🧹
+----+ +-------+ +-------+ +-----+
| | | New | | Old | | |
| MN | | AR / | | AR / | | HA |
| | | PMA | | PMA | | |
+----+ +-------+ +-------+ +-----+
| | | |
| | | 1 |
+-> | | |<------------|
| | | | |
Revocation | | | o 2 |
| | | | |
| | | | 3 |
+-> | | |------------>|
| | | |
Figure 4: Registration Revocation for Previous PMAso this is the cleanup for the old AR 🗑️ it's needed when the old AR has to delete its PMIPv4 and other associated states for a mobile device that has already moved over to another AR. because of that, it's an optional procedure for Proxy Mobile IP 🫧 the other option is that the new PMA tells the old PMA to clean up, but that alternative is out of the scope of this document, so we're not going there today 🙈
- once the mobility binding entry for a mobile device that moved to a new AR gets updated, the HA may send a Registration Revocation (as specified in RFC 3543 [RFC3543]) to the old PMA (specifically, the Foreign Agent entity) so it can clean up unused resources in an expeditious manner ⚡
- the old PMA removes the PMIPv4 states for the mobile device 🧼
- the old PMA sends a revocation acknowledgement to the HA ✅
4.2. Establishment of a Bi-Directional Tunnel 🚇
the PMA and HA set up a tunnel between them for the Home Address once the PMIPv4 registration message exchange is done 💜
4.2.1. Packet Forwarding 📦
the bi-directional tunnel between the PMA and the HA lets packets flow in both directions while the mobile device is connected on the visited network 🌈 all traffic to and from the mobile device goes through this tunnel, no exceptions bestie 💖
while the PMA is serving a mobile device, it MUST be able to intercept all packets sent from the mobile device and forward them out the tunnel created for supporting that mobile device 🫶 usually the forwarding is based on layer 2 information, like the source Media Access Control (MAC) address or the ingress interface. this is what lets overlapping IP addresses work for packets coming from the mobile devices. for example, the PMA forwards packets from mobile devices that share the same IP address to the tunnel for each mobile device, based on the source MAC address 🧠
the PMA de-encapsulates any packets it receives on the tunnel from the HA before forwarding them to the mobile device on its link. usually the forwarding is based on the destination IP address and the ingress HA tunnel (which may have a GRE key). that's how overlapping IP addresses get supported for packets headed to the mobile device. for example, the PMA forwards packets to mobile devices with the same IP address to the link for each mobile device, based on the GRE key value of the tunnel created for the HA that serves these mobile devices 🎀
the tunnel operation between the PMA and HA is the same as between the FA and HA in RFC 3344. the IP TTL (Time to Live), fragmentation, re-assembly, and so on logic all stays the same 🍓 the tunnel mode is IPinIP by default, and GRE is available as an option 🦋
4.2.2. Broadcast and Multicast 📣
broadcast packet processing for DHCP and ARP (Address Resolution Protocol) messages is covered in Section 6.3 and Section 6.1, respectively 🙌 for other kinds of broadcast packets, the PMA and HA process them in accordance with [RFC3344], [RFC3024], and [MIP4MCBC]. only the Direct Encapsulation Delivery Style is supported, because there's no encapsulation for packets between the mobile device and the PMA 💅
4.2.3. Forwarding between Devices on the Same PMA 🏠
when both communication peers are attached to the same PMA, the packet is forwarded as specified in Section 4.2.1 ✨ the traffic between them should be routed via the HA without taking a local shortcut on the PMA. this makes sure data-traffic enforcement at the HA doesn't get bypassed 🔥 no sneaky shortcuts, iykyk 🙈
4.3. Security Association between the PMA and the HA 🔐
the security relationship that protects the control message exchanges between the PMA and the HA may be either per node (meaning one security association for all mobile devices) or per MN (meaning a unique security association per mobile device) 💖 how you get the security association is outside the scope of this document 🫠
for per-node SA support, the FA-HA Authentication extension or IPsec (indicated in the PMIPv4 extension) is used to authenticate the signaling messages (including Registration Revocation [RFC3543]) between the PMA and HA. if you go with IPsec, Encapsulating Security Payload (ESP) [RFC4303] in transport mode with mandatory integrity protection should be used. the IPsec endpoints are the IP addresses of the PMA and HA 🛡️
for per-MN SA support, the MN-HA Authentication extension and/or MN-AAA Authentication extension are used to authenticate the signaling 🫧
the creation of the security association may be assisted by the AAA server at the time of access authentication 🧚
4.4. Registration Sequencing 🔢
the Identification field in the registration message gives replay protection and sequencing when the timestamp method is used 💫 it lets the HA know the order of messages from the same PMA or from different PMAs, based on the Identification field. the HA can also sync up the PMA's clock by using the Identification mismatch error code in the Proxy Registration Reply. that reply message wouldn't be necessary when the PMAs' clocks are synchronized using the Network Time Protocol [RFC1305] or some other method ⏰ also, using a nonce for sequencing and replay protection is outside the scope of this document 🙃
the method above is enough when there's a single source for signaling, like in the split PMA case 🌷 but in the integrated PMA case, the Proxy Registration Request comes from different sources (meaning different PMAs). if the previous PMA doesn't realize the mobile device has moved away and keeps sending re-registration, then the HA would get misinformed about where the device is 😭 that's why an integrated PMA MUST confirm that the mobile device is still attached before sending a Proxy Registration Request 🛑
note that for the split PMA model used in the WiMAX Forum (see Section 10), the PMIPv4 client stays anchored during handover (see Section 10.1). in this case, the PMIPv4 client is the only source of the PRRQ 🎯 however, there are cases, such as PMIPv4 client relocation and uncontrolled handover events, where more than one PMA performs registration. the same method used for the integrated PMA is used to make sure registration on the HA is sequenced properly 🦋
4.5. Mobile Device Interface Configuration 📱
usually the mobile device's interface needs an IP address, network prefix, default gateway, and DNS server addresses configured before the network connection can be used for communication 🌐 with some IP stacks, the default gateway IP address has to be on the same subnet as the mobile device's IP address. when the Home Agent's IP address isn't on the same subnet as the Home Address, vendor-specific extensions (e.g., [RFC4332]) or other methods MAY be used by the PMA to obtain the default gateway 🧚✨
4.6. Dynamic HA Discovery 🧚
Okay so the PMA can do dynamic HA discovery by sending the registration with the Home Agent field set to 0.0.0.0 or 255.255.255.255. 💅 The HA then sends back its own IP address in the Home Agent field, following "Mobile IPv4 Dynamic Home Agent (HA) Assignment" [RFC4433]. It's giving teamwork. 🫶
5. Proxy Mobile IPv4 Extensions ✨
Bestie, these PMIPv4 extensions are not required for base functionality, but they may be used in some cases where the features actually apply. 🎀 They go before the authentication extension (like the MN-HA or FA-HA Authentication extension) in the registration message, so the order matters! 💖
5.1. PMIPv4 Per-Node Authentication Method Extension 🔐
The Proxy Mobile IPv4 Authentication Method extension is the alternative way to authenticate the registration, instead of the default MN-HA Authentication extension from RFC 3344. 🦋 This extension MUST be included in the Registration Request and Registration Reply when the security association for authenticating the message is between the PMA and HA on a per-node basis. So basically a common key, or a set of keys (indexed by the SPI), gets used for message authentication by the PMA and HA. The key is independent of the mobile device, which is identified in the registration. 🌸
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Method |
+-+-+-+-+-+-+-+-+
PMIPv4 Per-Node Authentication Method Extension- Type:
47 (Proxy Mobile IPv4 Non-Skippable Extension) - Sub-Type:
1 (PMIPv4 Per-Node Authentication Method) - Length:
1 - Method: an 8-bit field that picks the authentication type for protecting the signaling messages. 🔥 IANA allocates and manages the values (0 - 255), and these ones are already assigned:
0: Reserved1: FA-HA Authentication2: IPsec Authentication
5.2. Proxy Mobile IPv4 Interface ID Extension 🌈
The Proxy Mobile IPv4 Interface ID extension tells everyone the interface address of the device used to attach to the network. 💜 It MAY be included in the Registration Request when the PMA knows about it.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PMIPv4 Interface ID Extension- Type:
147 (Proxy Mobile IPv4 Skippable Extension) - Length: the length of the extension in octets, not counting the Type and Length fields. 📏
- Sub-Type:
1 (PMIPv4 Interface ID) - Identifier: a variable-length octet sequence that holds an identifier of the interface. 🦄
5.3. Proxy Mobile IPv4 Device ID Extension 📱
The Proxy Mobile IPv4 Device ID extension identifies the device used to connect to the network. 🍓 It MAY be included in the Registration Request when the PMA is aware of it.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | ID-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PMIPv4 Device ID Extension- Type:
147 (Proxy Mobile IPv4 Skippable Extension) - Length: the length of the extension in octets, not counting the Type and Length fields.
- Sub-Type:
2 (PMIPv4 Device ID) - ID-Type: an 8-bit field that specifies the device ID type. IANA allocates and manages the values (0 - 255), and these are the assigned device ID types:
0: Reserved1: Ethernet MAC address2: Mobile Equipment Identifier (MEID)3: International Mobile Equipment Identity (IMEI)4: Electronic Serial Number (ESN)
- Identifier: a variable-length octet sequence that holds an identifier of the type named in the ID-Type field. 🪞
5.4. Proxy Mobile IPv4 Subscriber ID Extension 🎟️
The Proxy Mobile IPv4 Subscriber ID extension identifies the mobile subscription. 💫 It MAY be included in the Registration Request when the PMA is aware of it.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | ID-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PMIPv4 Subscriber ID Extension- Type:
147 (Proxy Mobile IPv4 Skippable Extension) - Length: the length of the extension in octets, not counting the Type and Length fields.
- Sub-Type:
3 (PMIPv4 Subscriber ID) - ID-Type: an 8-bit field that specifies the subscriber ID type. IANA allocates and manages the values (0 - 255), and these subscriber ID types are assigned:
0: Reserved1: International Mobile Subscriber Identity (IMSI)
- Identifier: a variable-length octet sequence that holds an identifier of the type named in the ID-Type field. 🫧
5.5. PMIPv4 Access Technology Type Extension 📡
The Proxy Mobile IPv4 Access Technology Type extension says what kind of radio-access technology the mobile device is attached through. 🛰️ It MAY be included in the Registration Request when the PMA knows that info. The HA can keep mobility on the same access technology type for a mobile device with multiple interfaces, as long as each interface is connected on a different access technology type. ✨ The HA does not include this extension in the matching Registration Reply.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Tech-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PMIPv4 Access Technology Type Extension- Type:
147 (Proxy Mobile IPv4 Skippable Extension) - Length:
2 - Sub-Type:
4 (Access Technology Type) - Tech-Type: an 8-bit field that specifies the access technology the mobile device is connected through to the access network. IANA allocates and manages the values (0 - 255), and these access technology types are assigned:
0: Reserved1: 802.32: 802.11a/b/g3: 802.16e4: 802.16m5: 3GPP EUTRAN/LTE6: 3GPP UTRAN/GERAN7: 3GPP2 1xRTT/HRPD8: 3GPP2 UMB
6. Appearance of Being at Home Network 🏡
Okay this one is iconic. 👑 The Mobile Node isn't aware of its own mobility and doesn't join in on handover signaling, so the network entities fake being the home network for the mobile device on the network. 🙈 From the device's point of view, it's acting like it's still at home. Meanwhile, the network is quietly steering the device's traffic to and from where it actually is, and it'll keep doing that even after it moves somewhere new. 🦋
An unmodified mobile device on a shared link uses ARP ([RFCARP]) to learn the MAC address of another host on the home network, gets an IP address and other host configuration through DHCP ([RFC2131]), and sends link-local multicast and broadcast packets. 💌 The network's answer to the host is the same as if the host were sitting on the home network. When the link state changes, some hosts use ARP, ICMP, and/or DHCP to check whether they've changed their point of attachment on the network. 🌷
6.1. ARP Considerations 🧦
For IEEE 802 type access networks (like WLAN or the WiMAX Ethernet Convergence Sublayer), the mobile device sends ARP requests for the Corresponding Node (CN) and the default gateway on the same network. 🧁 Keeping an ARP entry is there so the packet can get from the mobile device to the CN using the destination MAC address. The ARP procedure for mapping IP to MAC addresses isn't needed for 3GPP2's cdma2000 and the WiMAX IP Convergence Sublayer networks. 🙌
The access router is always the L2 endpoint for the mobile device. The destination MAC address in the packet doesn't have to be set to the CN's MAC address. As long as the access router can receive the packet, it gets forwarded toward the CN through the home network node (more details in Section 4.2.1). 🛣️ The mobile device's ARP table doesn't need CN MAC addresses in it for packets to reach the CNs. 💅
A mobile device keeps ARP entries for the default gateway and for hosts on the same subnet. No matter what those MAC addresses are, the AR receives the packets the mobile device sends. 📬
6.2. ICMP Considerations 🛜
For movement detection, certain network stacks on the mobile device send an ICMP request [RFCICMP] to the default gateway after noticing the link went down and back up. 🔁 The IP TTL in that message is set to 1, which checks whether the default gateway is still directly reachable on the access network. 🧠 The PMA MAY send an ICMP reply when it's providing Proxy Mobile IPv4 service for the mobile device. That reply tells the device it's still on the home network after the link state change. 🥰 This behavior has been seen in existing client implementations. "Detecting Network Attachment in IPv4 (DNAv4)" [RFC4436] can be employed too. 🫶
General ICMP traffic is handled as normal IP packets and tunneled between the PMA and HA. 🚇
6.3. DHCP Considerations ✨
Okay so DHCP [RFC2131] is how a mobile device gets an IP address and other host config parameters 🎀. The mobile device is expected to act like a totally normal DHCP client whenever it's connected to the network with Proxy Mobile IPv4 service 💅. There are two DHCP phases: bootup, and renewal/release 🦋. The bootup procedure relies on the DHCP relay agent to get a lease on the IP address for the DHCP client from the DHCP server 🧚. The DHCP client renews and releases the lease directly with the DHCP server 💖.
In Proxy Mobile IPv4, the mobile device boots up on a network that isn't the home network tied to its leased IP address 😭. It can also move to other networks that have nothing to do with that IP address 🌸. But the DHCP client on the mobile device keeps acting like a stationary device that's directly on the network associated with its IP address 🙈. The PMA and HA make the remote home network and the mobility events feel transparent by giving the DHCP client the response it expects ✨. Main character energy, literally 👑.
There are several ways the network infrastructure can interface with the mobile device so that the mobile device believes it's always fixed on the same network 🌈. The following methods are identified here, though others may be used as well 💜.
DHCP Server in the AR: The mobile device boots up and initiates DHCP. The procedure is described in Figure 1. The DHCP client renews or releases the IP address directly with the DHCP server in the AR 🍓. When the mobile device is on a different AR than the AR/DHCP server, the DHCP message from the client needs to be able to either be forwarded to the DHCP server in the previous AR or handled by the DHCP server in the new AR 🔥. When the DHCP lease time expires for the mobile device's IP address, or the DHCP release message is received on the current AR, the AR sends PMIPv4 de-registration to the HA 🦋.
DHCP Relay Agent in the AR: The mobile device boots up and initiates DHCP. The procedure is described in Figure 1. The DHCP client renews or releases the IP address directly with the DHCP server in the HA 💖. When the mobile device is on a different AR, DHCP messages from the client are relayed to the DHCP server in the HA 🧚. When the DHCP lease time expires for the mobile device's IP address, or the DHCP release message is received on the HA, the HA deletes the mobility binding entry for the mobile device and sends registration revocation [RFC3543] to the AR 💀.
6.4. PPP IPCP Considerations
When the mobile device accesses the network via PPP [RFC1661], LCP (Link Control Protocol) CHAP is used to authenticate the user 🔐. After authentication, the NAS (which is the AR/PMA) sends the Proxy Mobile IPv4 Registration Request to the HA 📨. The HA responds with the Home Address in the Proxy Registration Reply 🏡. The NAS informs the mobile device to use the Home Address during IPCP [RFC1332] 🫶. When the mobile device moves to a new NAS, the same procedure happens, and that mobile device keeps the same IP address for communication 🎀.
The message exchange is illustrated in Figure 1 🧁.
6.5. Link-Local Multicast and Broadcast Considerations
Depending on configuration policies, the PMA may tunnel all packets destined to Link-Local Multicast or Broadcast to the HA 🚇. The HA looks up the hosts that are in the same subnet and sends a duplicated packet to each of them 📬. Everyone gets the memo, iykyk 🙈.
7. Proxy Mobility Agent Operation
The PMA performs the functions of a Mobile Node entity as described in RFC 3344, with the exceptions identified below 🧚♀️.
- No agent discovery (i.e., agent solicitation and advertisement) is supported 🚫.
- The D-bit (De-encapsulation by MN) in the Registration Request is always set to zero 0️⃣.
The main responsibility of the PMA is to set up and maintain the routing path between itself and the HA for a mobile device that is attached on the network 🛣️. When it detects a mobile device is no longer attached, the routing path is torn down 💨. It's possible that the PMA functions may be split up in implementations such as WiMAX (Section 10) 🌸.
The PMA needs to know the following information, at a minimum, for sending a proxy registration 📝:
- NAI of the mobile device.
- MN-HA security association, when per-mobile device security association is used.
- FA-HA Mobility security association or IPsec security association when per-node security association is used. Note that these associations are specific only between PMA and HA, and are cryptographically unrelated to the associations between the MN and other network nodes 🔑.
- HA Address.
This information is typically downloaded from the AAA server during access authentication 📥.
8. Home Agent Operation
The Home Agent has the functionality described in RFC 3344 [RFC3344]. In addition, the following features are introduced by Proxy Mobile IPv4 💖:
- Sequencing between PRRQs from multiple PMAs. For the integrated PMA case, there is a period after handover that may result in both the new PMA and old PMA sending PRRQs. It is imperative that the old PMA confirm that the mobile device is attached before sending a PRRQ when the re-registration timer expires. This would ensure that the HA only receives registration from the PMA that is serving the mobile device 🚦. Not a single extra message, bestie 💅.
- Authentication of PRRQs based on per-node security associations (FA-HA AE or IPsec AH/ESP) is applicable in the integrated PMA case. The presence of MN-HA AE or MN-AAA AE in the PRRQ is not necessary in this case. Since PMIPv4 is based on signaling between the PMA and the HA, the security for the message can be authenticated based on the peers' relationship. The HA can authorize PMIPv4 service for the mobile device at the PMA by contacting the AAA server 🔒.
- The ability to process the Proxy Mobile IPv4 extensions defined in this document for enhanced capabilities of PMIPv4 ✨.
8.1. Processing Proxy Registration Requests
When a Proxy Registration Request is received, the HA looks up the mobility binding entry indexed by the NAI 🔍. If the entry exists, the HA compares the sequence numbers between the message and the mobility binding entry (MBE), if present. If the value in the message is zero or greater than or equal to the one in the MBE, the HA accepts the registration 🥳. The HA replies with a sequence number that is one greater than the larger value of either the MBE or the Proxy Registration Request 🔢. If the registration is denied, then the HA sends error code "Administratively prohibited (65)" 🚫. If the HA is not enabled with Proxy Mobile IPv4, or cannot process the Proxy Mobile IPv4 Extensions defined in this document, it sends a Registration Reply with error code PMIP_UNSUPPORTED ("Proxy Registration not supported by the HA") 😵. In the case when the PMA is not allowed to send a Proxy Registration Request to the HA, the HA sends a Proxy Registration Reply with error code PMIP_DISALLOWED ("Proxy Registrations from this PMA are not allowed") 🙅♀️.
A PMA receiving these error codes SHOULD NOT retry sending Proxy Mobile IPv4 messages to the HA that sent replies with these error codes 🛑.
9. Mobile Device Operation
As per this specification, a mobile device would function as a normal IPv4 host 💻. The required behavior of the node will be consistent with the base IPv4 specification [RFC0791] 📖. The mobile station will have the ability to retain its IPv4 address as it moves from one point of network attachment to the other, without ever requiring it to participate in any mobility-related signaling 🦋. Zero extra signaling. Pure vibes 🌸.
When booting up for the first time, a mobile device obtains an IPv4 address using DHCP or IPCP 🚀.
As the mobile device roams, it's always able to communicate using the obtained IP address on the home network 🏠. The PMA on the currently attached network signals to the HA to ensure a proper forwarding path for the mobile device's traffic 🛤️.
9.1. Initial Network Access
When the mobile device accesses the network for the first time and attaches to a network on the PMA, it presents its identity in the form of an NAI to the network as part of the network-access authentication process 🪪.
Once the address configuration is complete, the mobile device will always be able to use that IP address anywhere in the network 🌍.
9.2. Mobile Device Mobility
When a mobile device moves to a new PMA from another PMA, the following occurs 🏃♀️:
The mobile device may perform a network-access authentication with the new AR/PMA. If the authentication fails, the mobile device won't be able to use the link 🚷. After a successful authentication, the new PMA will have the identifier and the other profile data of the mobile device 📇. The new PMA can also obtain the mobile device's information using a context-transfer mechanism, which is out of the scope of this document 🔄.
Once the network-access authentication process is complete, the mobile device may sense a change in the Link Layer and use ARP, DHCP, and/or ICMP to detect if it's still on the same subnet 🧭. These mechanisms are handled by the network as described in "Appearance of Being At Home Network" (Section 6) 🏡.
9.3. Sending and Receiving Packets
All packets that are to be sent from the mobile device to the Corresponding Node (CN) will be sent as normal IPv4 packets, with the Source Address of the IPv4 header set to the Home Address and the Destination Address set to the Corresponding Node's IP address 📦. In Proxy Mobile IPv4 operation, the default gateway for the mobile device is set up to reach the PMA 🚪.
Similarly, all packets sent to the mobile device's IP address by the Corresponding Node will be received by the mobile device in the original form, without any tunneling overhead ✨.
For Proxy Mobile IP, the packet from the mobile device is transported to the HA to reach the destination, regardless of the destination IP address 🚚. For a CN with an IP address on the same network as the mobile device but that is physically located elsewhere, the HA will tunnel the packet to the CN 🌀. Otherwise, the HA forwards the traffic via normal routing 🛣️.
No special operation is required by the mobile device to either send or receive packets 🙌.
Mobile devices attached to the same PMA may be using different HAs for transporting their traffic 🌈.
10. Proxy Mobile IPv4 Use Case in WiMAX ✨
okay so the WiMAX Forum Network Working Group (NWG) uses Proxy Mobile IPv4 to give devices IPv4 connectivity and IP mobility 🛰️ the relevant spec from the WiMAX Forum is [NWG], and it's the main source for all of this.
Proxy Mobile IPv4 runs over NWG reference point 3 (R3) 🔥 most of the Proxy Mobile IPv4 procedures and requirements are written around mobility management over R3, so that's where the action is.
Here's the Proxy Mobile IPv4 use case from the WiMAX Forum spec, drawn out for you 👑
|
| CSN
|
|
+-------+ | +-------+
| | | | |
|AAAV |--------------|------------| AAAH |
| | | | |
| | | | |
+-------+ | +-------+
| | |
| | |
| | |
+------------------+ | |
| +-------+ | | |
| | NAS | | | |
| | PMIP | ASN1 | | |
| | Client| | | |
| +-------+ | | |
| | | | |
| | R4 | | |
| +-------+ | | +------+
+----+ | | FA, | | | PMIPv4 | |
| MN |-------| DHCP |---------------------------| HA |
+----+ | | Relay/| | | R3 | |
| | Server| ASN2 | | +------+
| +-------+ | |
| | |
+------------------+
Split PMA
Figure 5: WiMAX NWG Network Configuration for PMIPv4 UseSo, as the picture shows, WiMAX NWG uses the split PMA model 🧩 the PMIPv4 client is collocated with the NAS in ASN1 (aka, Authenticator ASN). The NWG architecture splits the network into two parts: the Access part, called the "Access Service Network" (ASN), and the Core part, called the "Connectivity Service Network" (CSN). The MN attaches to an 802.16 radio in the ASN2 (aka, Anchor Data Path Function) 📡 the radio (base station) connects to the Anchor Data Path Function (A_DPF) in ASN2, which then connects to the Authenticator ASN (NAS) in ASN1. ASN1 authenticates and authorizes the MN, and the AAA infrastructure is also used to authenticate and authorize the MN 🔐
Quick note though: during initial network entry by the MN, the PMA can be an integrated PMA with all the functions collocated in ASN1 🌸 because of mobility, the FA part of the PMA may need to move to a more optimized spot for better bearer management. Still, to describe the WiMAX-specific use case, this doc uses the split PMA model, since it's the more generic picture of the WiMAX NWG mobility framework 💅
The WiMAX NWG spec [NWG] defines a key bootstrapping scheme for Proxy Mobile IPv4 🗝️ it uses a per-MN security association for Proxy Mobile IPv4 operation, and the relevant keys (e.g., MN-HA key) are derived using EAP authentication, as specified in this document. For more info, check Section 4.3 of [NWG], the stage-3 spec.
Mobile IPv4 Registration Revocation is optionally supported in WiMAX 🦋 its security association is per node and is provided with FA-HA AE. The FA-HA key gets bootstrapped through the same key hierarchy described in Section 4.3 of [NWG]. Iconic key hierarchy behavior, honestly 😭
The Proxy Mobile IPv4 operation in WiMAX NWG lines up with the basic Proxy Mobile IPv4 operation described in Section 4 of this document 🎀 there are some specific considerations for WiMAX NWG 1.0.0 use of Proxy Mobile IPv4, and they're listed below:
- Use of per-MS SA for Proxy Mobile IPv4 registration. In this case, MN-HA AE is used. 🔑
- Use of split PMA to handle FA relocation while the PMIPv4 client remains anchored with the NAS (Authenticator ASN). 🧚
- Only the Proxy Mobile IPv4 Access Technology Type extension defined in this document is used in the NWG specification [NWG]. ✨
- GRE key identifier is optionally used between the HA and the PMA. 🌈
- The PMIPv4 client and the FA interact via the WiMAX-specific reference point and protocol (aka, R4). For more info, check the NWG specification [NWG]. 💜
- In order to handle inter-ASN (inter Access Router) handover and still let the MN use the same DHCP server's IP address that was sent in DHCPOFFER/ACK, the DHCP server (aka, proxy) functions in the ASN are required to be configured with the same IP address. 🫶
- The MN - AR (trigger for Proxy Mobile IPv4) interaction is based on DHCP. DHCPDISCOVER from the MN triggers the Proxy Mobile IPv4 process in the ASN. 🦋
10.1. Proxy Mobile IPv4 Call Flow Examples with Split PMA in WiMAX
okay bestie, since WiMAX uses the split PMA model, the call flows involve WiMAX proprietary signaling between the PMIPv4 client and the FA inside the PMA 🌸 here's how it plays out 👇
Split PMA
+-----------------------------------+
+----+ | +------+ +------+ +-----+ | +-----+
| | | | NAS/ | | Old | | New | | | |
| MN | | | PMIP | | FA | | FA | | | HA |
| | | |Client| | | | | | | |
+----+ | +------+ +------+ +-----+ | +-----+
| +----|------------|------------|----+ |
| | | PMIP Tunnel |
| | |<=======================>|
| | | | |
| | | R4 tunnel | |
| | |<==========>| |
| | 1 | | |
|<---------------------------------->| |
| | | | |
| | | 2 | |
| | |<---------->| |
| | 3 | | |
| |<----------------------- | |
| | | | |
| | 4 | | |
+-> | |------------------------>| |
| | | | | 5 |
| | | | |----------->|
| | | | | |
PMIP | | | | | 6 |
| | | | |<-----------|
| | | | | |
| | | 7 | | |
+-> | |<------------------------| |
| | | | |
| | | 8 | |
| | |<---------->| |
| | | | |
| 9 | | |PMIP Tunnel |
Data |<---------------------------------->|<==========>|
Forwarding | | | | |
Figure 6: Proxy Handover Operation in WiMAX with Split PMAIn this scenario, the MN has moved into a new FA's area (known as the Data Path Function in WiMAX) 🧭 the old FA and the new FA talk to each other, and also to the PMIPv4 client, over a WiMAX-specified R4 reference point to pull off the handover. Here are the steps:
- The mobile device sets up an L2 link with a base station (not shown), which connects to a new FA (aka, new Data Path Function in WiMAX). Note that, in this case, the MN does not perform authentication and authorization. The PMIPv4 tunnel remains between the old FA (aka, old Data Path Function in WiMAX). The data flows through the PMIPv4 tunnel between the HA and the old FA, then through the WiMAX-specific R4 tunnel between the old FA and the new FA, and from the new FA to the MN. 📶
- The new FA interacts with the old FA using a WiMAX-specific R4 reference point to kick off the handover process. 🤝
- The new FA uses the WiMAX-specific R4 reference point to ask the PMIPv4 client to begin the PMIPv4 handover. 🙌
- Triggered by step 3, the PMIPv4 client sends a PRRQ to the new FA. The PRRQ contains the FA-CoA of the new FA. The Home Address field is set to the assigned IP address of the Mobile Node. The PRRQ is embedded in the WiMAX-specific R4 packet. 📦
- The new FA forwards the PRRQ to the HA. 🚀
- The Home Agent updates the existing mobility binding entry for the mobile device upon processing the PRRQ, then responds to the new FA with PRRP. 💌
- The new FA encapsulates the PRRP in a WiMAX-specific R4 packet and forwards it to the PMIPv4 client. 🎁
- The new FA and the old FA swap WiMAX-specific R4 messages to confirm the handover. The old FA cleans up its resources for the MN, and R4 bearer forwarding also stops at this point. 🧹
- Forward and reverse direction traffic now flows via the new FA. The handover is complete at this point 🎉 literally the glow-up we wanted 💖
11. Proxy Mobile IPv4 Use Case in 3GPP2 ✨
okay so 3GPP2 uses Proxy Mobile IPv4 to give mobility service in two scenarios (see the figures below) 🦋:
- Mobility between the base station (BS) and access gateway (AGW) 💖
- Mobility between the AGW and the Home Agent (HA). 🫶
so in use case 1, the BS is the PMA and the AGW is the HA 🌸. in use case 2, the AGW is the PMA and the HA is the Home Agent 💅. literally that's the whole flip ngl 😭
RAN Core
+-------+ +------+
+----+ | BS/ | PMIPv4 | |
| MN |------| PMA |-----------------------| AGW/ |
+----+ | | | HA |
| | +------+
+-------+
Integrated PMA
Figure 7: 3GPP2's PMIPv4 Use Case 1 - BS-AGW Interface Mobility
RAN Core
+-------+ +------+
+----+ | AGW/ | PMIPv4 | |
| MN |------| PMA |-----------------------| HA |
+----+ | | | |
| | +------+
+-------+
Integrated PMA
Figure 8: 3GPP2's PMIPv4 Use Case 2 - AGW-HA Interface Mobilitythe simplified 3GPP2 architecture is shown below 🎀. for the full details, check the 3GPP2 Converged Access Network (CAN) architecture ([3GPP2]) 🌈.
RAN Core
-----------^------------ -------^-------------
| | | |
V V V V
+------+ +------+ +-----+
+----+ | | PMIPv4 | | PMIPv4 | |
| MN |------| BS |------------| AGW |-----------| HA |
+----+ | | | | | |
+------+ +------+ +-----+
Figure 9: Simplified 3GPP2 Architecturethe Proxy Mobile IPv4 usage scenario in 3GPP2 (case 1) looks like this 👑:
+----+ +-------+ +-------+ +------+
| | | | | | | |
| MN | | BS/ | | HAAA | | AGW/ |
| | | PMA | | | | HA |
+----+ +-------+ +-------+ +------+
| | | |
| 1a | 1b | |
|<------------->|<----------->| |
| | | |
| 2 | | |
|-------------->| | |
| | 3 | |
| |----------------------->|
| | | |
| | 4 | |
| |<-----------------------|
| 5 | | |
|<--------------| | |
| | | |
| 6 | | |
|<======================================>|
| | | |
Figure 10: Network Connection Setup (use case 1)here's how the steps go 🧚:
1a. the MN does layer 2 establishment with the BS/PMA and does access authentication/authorization 🔐. during this bit, the MN runs EAP over Ultra Mobile Broadband (UMB) 💜. the BS is the NAS here 🙈.
1b. the BS swaps AAA messages with the Home AAA server via the AR (not shown in the figure) to authenticate the MN ✨. as part of this step, the AR might download some info about the MN (e.g., user's profile, handset type, assigned Home Agent address, and other capabilities of the MN) 🍓. that info gets passed to the PMA/BS (as necessary) to set up the PMIPv4 tunnel in the next step(s) 🦋.
- the MN sends layer 2 signaling messages to the BS/PMA to kick off the PMIPv4 tunnel setup 🌸.
- triggered by step 2, the PMA/BS sends a PRRQ to the AGW/HA 💖. the HA's address is either received at step 1b from the Home AAA server (HAAA) or is discovered by other means. the PRRQ contains the Care-of Address (CoA) of the PMA (collocated FA in this case). the HoA field is set to all zeros (or all ones). the PRRQ is protected by the method described in this document. the derivation and distribution of the MN-HA or FA-HA key is outside the scope of this document 🔥.
- the AGW/HA registers the MN's session, assigns a symmetric GRE key, and returns this key in the PRRP to the BS/PMA 💅.
- the BS/PMA responds back to the MN with a layer 2 signaling message 🫶.
- at this step, the MN gets an IP address and is connected to the network (via the AGW) 🌈.
in use case 2, the same procedures are followed except the PMIPv4 tunnel is set up between the AGW and the HA 🎀. in this case, GRE tunneling may not be used 💀.
11.1. Handover Considerations in 3GPP2 🦋
there are some special handover considerations in 3GPP2's Proxy Mobile IPv4 use case 💜. here's an illustration of the specific use case:
+----+ +-------+ +-------+ +-------+
| | | | | | | |
| MN | | New | | AGW/ | | Old |
| | | PMA/BS| | HA | | PMA/BS|
+----+ +-------+ +-------+ +-------+
| | | |
| | 1 | |
| |------------->| |
| | | |
| | | |
| | o 2 |
| | | |
| | | |
| | 3 | |
| |<-------------| |
| | | |
| | | |
| | 4 | |
| |<----------------------->|
| | | |
| | | |
| | | o 5
| | | |
| | | |
Figure 11: 3GPP2 Registration Revocation for Previous PMAhere are the steps 🌸:
- the MN attaches to the new BS (L2 gets established) ✨. there's an ongoing mobility binding entry (MBE) in the AGW for the MN. the PMA in the new BS sends a PRRQ to the AGW 💖.
- the AGW gets a Proxy Registration Request for a Mobile Node and notices it already has an existing Mobility Binding Entry (MBE) 👀. the AGW validates the PRRQ from the new BS and updates the MBE for the MN. the MBE stays tentative at this point 🫧.
- the AGW sends a Proxy Registration Reply to the new BS. no Registration Revocation is used in the 3GPP2's use case 🚫.
- a 3GPP2's proprietary PMA movement notification message may be swapped between the AGW and the old BS 💌.
- the MBE update with the new BS gets committed at this step 🔒.
12. IANA Considerations 🎀
this spec registers 47 for the Proxy Mobile IPv4 Non-Skippable Extension and 147 for Proxy Mobile IPv4 Skippable Extension, both of which are described in Section 5 💅. the ranges for Mobile IPv4 [RFC3344] extension types are defined at http://www.iana.org. this spec also creates a new subtype space for the type number of the extensions 🧚. the subtype value 1 is defined for the PMIPv4 Non-Skippable Extension. the subtype values 1 to 4 are defined for the PMIPv4 Skippable Extension. similar to the procedures for Mobile IPv4 number spaces, future allocations from the number space require expert review [RFC5226] 👑.
the PMIPv4 Per-Node Authentication Method extension (defined in Section 5.1 of this document) introduces a new authentication method numbering space, where the values from 0 to 2 have been assigned per this document. approval of new Access Technology type values is to be made through IANA Expert Review 🌈.
the PMIPv4 Device ID extension (defined in Section 5.3 of this document) introduces a new ID type numbering space, where the values from 0 to 4 have been assigned per this document. approval of new Access Technology type values is to be made through IANA Expert Review 🍓.
the PMIPv4 Subscriber ID extension (defined in Section 5.4 of this document) introduces a new ID type numbering space, where the values from 0 to 1 have been reserved by this document. approval of new Access Technology type values is to be made through IANA Expert Review 🦋.
the PMIPv4 Access Technology Type extension (defined in Section 5.5 of this document) introduces a new technology type numbering space, where the values from 0 to 8 have been reserved by this document. approval of new Access Technology type values is to be made through IANA Expert Review 💜.
12.1. Mobile IPv4 Extension Types 🌸
this document introduces the following Mobile IP extension types 🫶.
Name : Proxy Mobile IPv4 Non-Skippable Extension
Type Value : 47
Section : 5
Name : Proxy Mobile IPv4 Skippable Extension
Type Value : 147
Section : 512.2. Mobile IPv4 Error Codes 💀
this document introduces the following error codes that can be returned by the HA in a Proxy Registration Reply 🔥.
Name Value First referenced
---- ----- ----------------
PMIP_UNSUPPORTED 149 Section 8.1 of RFC 5563
PMIP_DISALLOWED 150 Section 8.1 of RFC 556313. Security Considerations 🔐
okay this part is SERIOUS bestie 😭🔐. the functionality in this document is protected by the authentication extensions described in RFC 3344 [RFC3344] or IPsec [RFC4301] 🛡️. each PMA needs to have a security association (e.g., MN-HA, FA-HA, IPsec AH/ESP) with the HA to register the MN's IP address 🫧. the security association can be provisioned by the administrator or dynamically derived 💅. the dynamic key derivation and distribution for this scheme is outside the scope of this document 🚫.
14. Acknowledgements 🫶
the authors would like to thank the following individuals for their review, comments, and suggestions to improve the content of this document 💖.
Shahab Sayeedi (Motorola), Alper Yegin (Samsung), Premec Domagoj (Siemens), Michael Hammer (Cisco), Jun Wang (Qualcomm), Jayshree Bharatia (Nortel), Semyon Mizikovsky (Alcatel-Lucent), Federico De Juan Huarte (Alcatel-Lucent), Paula Tjandra (Motorola), Alice Qinxia (Huawei), Howie Koh (Greenpacket), John Zhao (Huawei), Pete McCann (Motorola), and Sri Gundavelli (Cisco) 🌈✨.
15. References 📚
15.1. Normative References 📚
okay bestie, these are the docs this spec totally leans on, so they're the ones you need to read first 💖
- [3GPP2] "3GPP2 Basic IP Service for Converged Access Network", X.S0054-100-0 Version 2.0, August 2008.
- [NWG] "WiMAX Forum Network Architecture (Stage 3: Detailed Protocols and Procedures)" Release 1, Version 1.2.3, July 2008.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
- [RFC3024] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
- [RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
- [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4", RFC 3543, August 2003.
15.2. Informative References 🦋
these ones are more like background reading, but they're super useful for the full picture ✨
- [MIP4GREKEY] Yegani, P., "GRE Key Extension for Mobile IPv4", Work in Progress, June 2007.
- [MIP4MCBC] Chakrabarti, S., "IPv4 Mobility extension for Multicast and Broadcast Packets", Work in Progress, November 2007.
- [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
- [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
- [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
- [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
- [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
- [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
- [RFC4058] Yegin, A., Ed., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, "Protocol for Carrying Authentication for Network Access (PANA) Requirements", RFC 4058, May 2005.
- [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
- [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
- [RFC4332] Leung, K., Patel, A., Tsirtsis, G., and E. Klovning, "Cisco's Mobile IPv4 Host Configuration Extensions", RFC 4332, December 2005.
- [RFC4433] Kulkarni, M., Patel, A., and K. Leung, "Mobile IPv4 Dynamic Home Agent (HA) Assignment", RFC 4433, March 2006.
- [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
- [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC5454] Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile IPv4", RFC 5454, March 2009.
- [RFCARP] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
- [RFCICMP] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
Authors' Addresses 🌸
meet the squad who wrote this! 💜
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
Parviz Yegani
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089-1206
EMail: pyegani@juniper.net
Kuntal Chowdhury
Starent Networks
30 International Place
Tewksbury, MA 01876
USA
EMail: kchowdhury@starentnetworks.com📦 where this page comes from
- ietf: rfc5563 2010-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms