Mobile IPv4 Dynamic Home Agent (HA) Assignment
Extracted elements (26)
ALL-ZERO-ONE-ADDR disambiguates between two preferences: 255.255.255.255 signals a preference for an HA in the home domain, while 0.0.0.0 indicates no preference, allowing the network to assign any suitable HA regardless of domain proximity.
The existing Mobile IPv4 mechanism using subnet-directed broadcast for HA discovery was designed for static home addresses and is unreliable in practice because routers drop directed broadcast packets by default (per BCP 34 / RFC 2644, addressing Smurf DoS attacks). This document uses a unicast destination IP address instead, avoiding the multi-HA response problem.
The HA selection mechanism is intentionally left outside the scope of the specification. The document only defines the messaging (Registration Request/Reply extensions and error codes); the network can use any criteria such as load balancing, geographical proximity, DHCP option 68, AAA, or DNS to select the optimal HA.
A legacy mobile node that does not implement this specification and does not set the HA field to ALL-ZERO-ONE-ADDR will continue to be registered with its statically configured HA as per RFC 3344, with no change in behavior.
Legacy foreign agents may forward a Registration Request with HA field ALL-ZERO-ONE-ADDR by using ALL-ZERO-ONE-ADDR as the destination IP, causing the packet to be dropped or mishandled. The MN should fall back to setting the HA field to the actual HA unicast address (step 2 of Section 4.1) if no reply is received or error code 70 (poorly formed request) is returned.
Legacy home agents may reject Registration Requests with the HA field set to ALL-ZERO-ONE-ADDR using error code 136 (non-unicast HA address). Some legacy implementations may coincidentally process such requests correctly, but this cannot be relied upon.
If a Registration Reply is received with code REDIRECT-HA-REQ, the MN MUST authenticate the Reply based on the HA address in the HA field and attempt Registration with the HA address specified in the Redirected HA Extension. The MN MUST put the Redirected HA address as the Requested HA Extension of the new Registration Request.
If the FA cannot obtain the Requested HA to which to forward a Registration Request from the MN, it MUST reject the request with error code NONZERO-HA-REQD (90).
If the MN has included the Requested HA Extension, the FA MUST forward the Registration Request to the address in this extension. If the HA address in this extension is not a routable unicast address, the FA MUST reject the request with error code NONZERO-HA-REQD.
If the Registration Request contains the Requested HA Extension, the HA address in that extension must match the destination IP of the Request. If it does not match, the Requested HA MUST reject the Registration Request with error code 136.
The mobile node MUST maintain the remaining Mobile IP session with the Assigned HA once registration is successful.
The mobile node MUST use the Network Access Identifier (NAI) extension when requesting a dynamically assigned HA. The Home Address field is consequently set to 0.0.0.0.
The Redirected HA Extension MUST be included in the Registration Reply when the reply code is REDIRECT-HA-REQ.
The Registration Request MUST be protected by a valid authenticator as specified in Mobile IPv4 (RFC 3344) or Mobile IPv4 Challenge/Response Extensions (RFC 3012).
The Requested HA address (destination IP of the Registration Request) MUST be a unicast IP address. A valid unicast IP address MUST be used as the HA address in the Requested HA Extension.
When using co-located CoA, the MN MUST cache the Assigned HA address for the length of the Mobile IP session and MUST use this cached address as the home agent address in subsequent Re-Registration and De-Registration Requests.
While dynamic HA assignment is in progress and the MN has not successfully anchored at a home agent, the MN MUST set the Home Agent field in the Registration Request to ALL-ZERO-ONE-ADDR (either 255.255.255.255 or 0.0.0.0).
While requesting dynamic HA assignment and registering directly with an HA using co-located CoA, the Requested HA Extension MUST be included and MUST contain the address of the HA to which the Registration Request is sent. The HA address in the extension MUST match the destination IP of the Request.
ALL-ZERO-ONE-ADDR is defined as either 0.0.0.0 or 255.255.255.255. An address of 255.255.255.255 indicates a preference for an HA in the home domain; 0.0.0.0 indicates no preference for home vs. visited domain.
The Dynamic HA Assignment mechanism defines three roles: Requested HA (the unicast destination of the Registration Request), Assigned HA (the HA that accepts and creates a mobility binding), and Redirected HA (an alternate HA suggested by a rejecting HA via the REDIRECT-HA-REQ error code).
Two error codes are defined: NONZERO-HA-REQD (value 90, rejection by FA) indicates that a non-zero HA address is required in the Registration Request; REDIRECT-HA-REQ (value 143, rejection by HA) instructs the MN to re-register with the redirected HA specified in the Redirected HA Extension.
IANA recorded three values: NONZERO-HA-REQD (90) as a Mobile IP FA rejection code (range 64-127); REDIRECT-HA-REQ (143) as a Mobile IP HA rejection code (range 128-192); and Dynamic HA Extension type 139 as a skippable extension at the home agent (range 128-255).
A man-in-the-middle can capture a Registration Request with HA field set to ALL-ZERO-ONE-ADDR and forward it to multiple HAs, potentially causing more than one HA to create a mobility binding for a given MN. The MN can mitigate this by using a short lifetime (e.g., 5 seconds) in such Registration Requests, and by including the Requested HA Extension (which makes the attack harder since the request is directed to a specific unicast address).
The specification does not change the security model of Mobile IPv4 (RFC 3344). Registration Requests and Replies are protected by authenticators per RFC 3344 and RFC 3012. Security associations between MN and HA may be dynamically derived via AAA infrastructure (RFC 3957), allowing any HA in the local domain to proxy-authenticate the MN.
Dynamic HA assignment flow: MN sets HA field to ALL-ZERO-ONE-ADDR and sends Registration Request to Requested HA (directly or via FA). On success, HA responds with its own address as Assigned HA and MN anchors there for the session. On REDIRECT-HA-REQ, MN extracts Redirected HA from extension, sends new Registration Request to that HA, and detects loops by tracking previously redirected HAs.
The Dynamic HA Address Extension (Type 139, skippable) contains a 1-byte Type, 1-byte Subtype, 2-byte Length (always 4), and a 4-byte HA-Address field. Subtype 1 = Requested HA Extension; Subtype 2 = Redirected HA Extension.