RFC 4433
Mobile IPv4 Dynamic Home Agent (HA) Assignment
RFC 4433 (Part 1 of 5) 💖
Title block tea 🍵 This one is Mobile IPv4 Dynamic Home Agent (HA) Assignment, from the Network Working Group. It was written by M. Kulkarni, A. Patel, and K. Leung, all from Cisco Systems Inc. It's on the Standards Track and dates to March 2006. The title block doesn't list anything it obsoletes or updates, so there's nothing to flag there. 🎀
Status of This Memo ✨
okay so this one is an Internet standards track protocol for the Internet community, and it's openly asking for discussion and suggestions for improvements 🫶 If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). And distribution of this memo is unlimited, so share it with everyone 🌸
Copyright Notice 💅
Copyright (C) The Internet Society (2006).
Abstract 🦋
Mobile IPv4 (RFC 3344) uses the home agent (HA) to anchor sessions of a roaming mobile node (MN). This doc proposes a messaging mechanism for dynamic home agent assignment and HA redirection. The goal is to give you a way to assign an optimal HA for a Mobile IP session, while still allowing any suitable method for HA selection 🧚
Table of Contents 📚
1. Introduction ....................................................3
2. Requirements Terminology ........................................3
3. Problem Statement ...............................................5
3.1. Scope ......................................................5
3.2. Dynamic Home Agent Discovery in Mobile IPv4 ................5
3.3. NAI Usage and Dynamic HA Assignment ........................6
3.4. Dynamic HA Extension .......................................6
3.4.1. Requested HA Extension ..............................7
3.4.2. Redirected HA Extension .............................7
4. Messaging Mechanism for Dynamic HA Assignment/Redirection .......7
4.1. Messaging for Dynamic HA Assignment ........................7
4.1.1. Example with Message Flow Diagram ...................8
4.2. Messaging for HA Redirection ..............................10
4.2.1. Example with Message Flow Diagram ..................12
5. Mobility Agent Considerations ..................................14
5.1. Mobile Node Considerations ................................14
5.1.1. MN Using FA CoA ....................................14
5.1.2. MN Using Co-Located CoA ............................15
5.1.3. Refreshing Assigned HA Address on Mobile Node ......16
5.2. Foreign Agent Considerations ..............................16
5.3. Home Agent Considerations .................................17
5.3.1. Assigned Home Agent Considerations .................17
6. Requested Home Agent Selection .................................19
7. Error Values ...................................................20
8. IANA Considerations ............................................20
9. Security Considerations ........................................20
10. Backward-Compatibility Considerations .........................21
11. Acknowledgements ..............................................23
12. Normative References ..........................................231. Introduction ✨
this doc adds to the Mobile IP protocol [1] by proposing a messaging mechanism for dynamic home agent assignment and home agent redirection during initial registration. The goal is to assign an optimal HA for a Mobile IP session 🎀 The mobile node MUST use the Network Access Identifier (NAI) extension [2] when requesting a dynamically assigned HA. no skipping that one, bestie 🙈
so here's how the MN asks for a dynamically assigned HA: it sets the HA field in the initial Registration Request to ALL-ZERO-ONE-ADDR (defined in Section 2). If the request is accepted, the HA sends back a successful Registration Reply that contains the HA's own address 💜 But the requested HA can suggest an alternate HA instead. When it does, the Registration Reply gets rejected with a new error code, REDIRECT-HA-REQ, and the alternate HA address is carried in a new extension called the Redirected HA Extension 🦋
this document also defines a new Requested HA Extension, for use in Registration Requests when the HA field is set to ALL-ZERO-ONE-ADDR. The Requested HA address is basically a hint to the network about the MN's preferred HA 🍓
the messaging mechanism is defined here so the MN can request and receive a dynamic HA address in Mobile IP messages. BUT the way the network actually picks an HA for the MN is outside the scope of this document 🙅♀️ For example, the selection can be made by any network node that gets the Registration Request (or info about it), like a Foreign Agent, an AAA server, or a home agent. The node doing the picking can use a bunch of criteria, including but not limited to HA load-balancing, geographical proximity, administrative policy, etc. 👑
2. Requirements Terminology 🌈
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6] 🧠
The Mobile-IP-related terminology described in RFC 3344 [1] is used in this document. On top of that, these terms are used too:
ALL-ZERO-ONE-ADDR: IP address 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. An address of
0.0.0.0 indicates no preference for home vs.
visited domain.
Requested HA: Destination IP address of home agent that the
Registration Request is sent to. Must be a
unicast IP address. This address can be
obtained as described in Section 6.
Note that this specification defines a new
"Requested HA Extension" in Section 3.4, which
is different from the term "Requested HA".
Assigned HA: The HA that accepts an MN's Registration Request
and returns a successful Registration Reply.
Redirected HA: If the registration is rejected with error code
REDIRECT-HA-REQ, the HA being referred to is
specified in a new extension (Redirected HA
Extension).
AAA server: Authentication, Authorization, and Accounting
Server.
DNS: Domain Name System.
DHCP: Dynamic Host Configuration Protocol.
MN: Mobile node as defined in Mobile IPv4 [1].
HA: Home agent as defined in Mobile IPv4 [1].
FA: Foreign Agent as defined in Mobile IPv4 [1].
CoA: Care-of Address.
CCoA: Co-located Care-of Address.
MN HoA: Mobile node's home address.
NAI: Network Access Identifier [2].
Src IP: Source IP address of the packet.
Dest IP: Destination IP address of the packet.
RRQ: Registration Request.3. Problem Statement 🔥
the Mobile IPv4 NAI Extension for IPv4 [2] introduced the idea of identifying an MN by its NAI, and enabling dynamic home address assignment. When the home address is dynamically assigned, it's desirable to discover the home agent dynamically, or to tell the MN about an optimal HA to use, for a bunch of reasons, such as:
- If the distance between the visited network and the home network of the mobile node is large, the signaling delay for these registrations may be long. In that case the MN gets anchored to its distant home agent, so the tunneled traffic has to travel a long distance between the home agent and the mobile node 🌍 If the mobile node can be assigned a home agent that's close by when a Mobile IP session starts, it can drastically reduce the latency between the home agent and mobile node ✨
- In a large-scale Mobile IP deployment, it's a real pain to provision MNs with multiple HA addresses 😭
- It's desirable to get some form of load balancing between multiple HAs in the network. Dynamic HA assignment and/or HA redirection lets the network pick the optimal HA from a set of HAs, and that's how you get load balancing across a group of HAs 💖
- Local administrative policies. 🎀
3.1. Scope 🧚
this spec does not address the problem of distributing a security association between the MN and HA. That association can either be statically preconfigured or dynamically distributed using other mechanisms [7] 🔐
The document introduces the terms Requested/Assigned/Redirected HA (Section 6). Finding candidate HA addresses to put into the Redirected HA Extension can happen through various means that are network and/or deployment specific, so those are outside the scope of this spec 🌸
The MN MAY request dynamic HA assignment when it isn't aware of any HA address, and even when it's aware of at least one HA address 🫶
3.2. Dynamic Home Agent Discovery in Mobile IPv4 🌙
Mobile IPv4 [1] specifies how the mobile node discovers its home agent: it uses the subnet-directed broadcast IP address in the home agent field of the Registration Request. This was designed for mobile nodes with a static home address and subnet prefix, anchored on a fixed home network. But if you use a subnet-directed broadcast as the destination IP address of the Registration Request, the Registration Request is unlikely to reach the home subnet, because routers will drop these packets by default 🙃 See CERT Advisory CA-1998-01 Smurf IP Denial-of-Service Attacks [3] for more on that 💀
3.3. NAI Usage and Dynamic HA Assignment 🪄
The Mobile IPv4 NAI Extension for IPv4 [2] introduced the idea of identifying an MN by its NAI and enabling dynamic home address assignment. This document requires that, while using dynamic HA assignment, the MN MUST use the NAI and obtain a home address. The MN can still suggest a static home address in the Registration Request, but it has to take the address in the Registration Reply as the home address for the session. This is compatible with the procedures documented in the NAI specification [2] ✨
3.4. Dynamic HA Extension 🍓
The Dynamic HA Extension, shown in Figure 1, contains the address of the HA. It's a generic extension, so it can be used in Registration Request and Reply messages. It's a skippable extension 💅
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 | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Dynamic HA Address ExtensionHere's the breakdown of each field 🔍
Type:DYNAMIC-HA-ADDRESS (skippable)is139, and it specifies the dynamic HA address.Subtype: defines how this extension is used:1= Requested HA Extension2= Redirected HA Extension
Length: indicates the length of the extension, not including the type, subtype, and length fields.Lengthis always4bytes. 📏HA-Address: the address of the home agent. 🏡
part 1 is all wrapped up, and there's more coming! 🌷
3.4.1. Requested HA Extension 🎀
okay so the Requested HA Extension is a Dynamic HA Extension of subtype 1 🦋
the MN can pop this into the Registration Request as a little hint to the network about where it'd like to be anchored 💜
this extension holds the address of the HA. a valid unicast IP address MUST be used as the HA address in this extension, no exceptions 💅
if there's no FA, the Registration Request just goes straight to this HA. if there IS an FA, the FA MUST forward the Registration Request to the HA address sitting in this extension 🫶
3.4.2. Redirected HA Extension ✨
the Redirected HA Extension is a Dynamic HA Extension of subtype 2 🌸
this one holds the address of the HA where the MN should try its next registration. so if the HA gets a Registration Request and wants to suggest a different HA, it sends back a Registration Reply with the new error code REDIRECT-HA-REQ, and the alternate HA address goes in this extension 🍓
the Redirected HA Extension MUST be included in the Registration Reply whenever the reply code is REDIRECT-HA-REQ 👑
4. Messaging Mechanism for Dynamic HA Assignment/Redirection 🌈
this spec gives us two ways to get a home agent assigned:
- (a) Dynamic HA assignment (covered in Section 4.1) 🧚
- (b) HA redirection (covered in Section 4.2) 🌸
4.1. Messaging for Dynamic HA Assignment 💖
here's the sequence of events when the MN asks for dynamic home agent assignment:
- The MN sets the Home Agent address field in the Registration Request to
ALL-ZERO-ONE-ADDR. If the MN already knows a HA address it likes, it can drop that address into the Requested HA Extension in the Registration Request. If the HA doesn't support the Requested HA Extension, check out step 2 below 🙈 - this step is for an MN that knows the HA address and still wants dynamic HA assignment, so it kind of replaces step 1. the MN also uses this when it finds a legacy FA in the path, or when the known HA doesn't support the Requested HA Extension (see Section 10) 🔥
The MN sets the Home Agent address field in the Registration Request to the HA address, instead of ALL-ZERO-ONE-ADDR. It also adds that same HA address in the Requested HA Extension in the Registration Request.
- The MN (if it's using a co-located CoA and registering directly with the HA) or the FA (if the MN is registering through the FA) sends the Registration Request to the "Requested HA". If the Requested HA Extension is there, the Requested HA is whatever's in the "HA Address" of that extension ✨
Per Section 10, if there's a legacy FA, the legacy FA forwards the Registration Request to the address in the HA field of the request. That means the MN uses step 2 above with a legacy FA instead of step 1 🫶
- the "Requested HA" is the home agent that processes the Registration Request following Mobile IPv4 [1] and this document. for a successful Registration Request, it creates a mobility binding and sends a Registration Reply back to the MN 💅
- the MN gets an "Assigned HA" address from the HA field in the successful Registration Reply and uses it for the rest of the session. (fun fact: the "Assigned HA" is always the same as the "Requested HA" 👑)
- renewal Registration Requests go to the Assigned HA 💜
Section 5.3.1 breaks down the Assigned HA in detail, and Section 6 has some ideas on how to pick the Requested HA 🦋
4.1.1. Example with Message Flow Diagram 🎀
a message flow diagram makes this way easier to picture, so here's one 🧚
Figure 2 shows one specific example: a mobile node using an FA-located Care-of Address (FA CoA), with an FA that understands the Requested HA Extension per this spec ✨
other stuff, like a co-located care-of address or a legacy HA or FA, isn't covered below, but it works in a similar way 🌸
MN FA Requested/Assigned HA
| 1 | |
|------------>| 2 |
| |--------------->|
| | |
| | |
| | 3 |
| 4 |<---------------|
|<------------| |
| | |
| | 5 |
|----------------------------->|
| | |Figure 2: Example Message Flow for Dynamic HA Assignment
- The MN sets the Home Agent address field in the Registration Request to
ALL-ZERO-ONE-ADDR. Since this example uses FA CoA, the MN sends the Registration Request to the FA. The Registration Request looks like this:
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| MN | FA | | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+If the MN knows a desired HA address, it can add that address to the Requested HA Extension in the Registration Request as a hint. That extension isn't shown above 💖
- The FA sends the Registration Request to the Requested HA. If the Requested HA Extension is present, the Requested HA is the HA address in that extension. If it isn't present, the FA figures out the Requested HA through means outside the scope of this spec 🙈 The Registration Request looks like this:
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA |Requested HA| | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+(If the MN includes the Requested HA Extension, the FA copies that extension. Then the FA forwards the Registration Request, along with the Requested HA Extension, to the HA address specified in it 🔥)
- The HA processes the Registration Request following Mobile IPv4 [1] and the messaging defined in this document. For a successful request, it creates a mobility binding and becomes the Assigned HA. Then it sends a Registration Reply to the FA, which looks like this:
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
|Assigned| Src IP of | | Assigned HA |FA CoA/|
| HA | the RRQ | | | |
+-----------------------------------------------------------+- The FA relays the Registration Reply to the MN, which looks like this:
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA | MN | | Assigned HA |FA CoA/|
+-----------------------------------------------------------+- The MN gets the Assigned HA address from the HA field in the successful Registration Reply and uses it for the rest of the session ✨ Later Re-Registration or De-Registration Requests go straight to the Assigned HA. The Home Agent address field in those Registration Requests is set to
ALL-ZERO-ONE-ADDR. And yep, the Assigned HA is the same as the Requested HA 💅
4.2. Messaging for HA Redirection 🦋
this section covers what happens when the Requested HA doesn't accept the Registration Request and redirects the mobile node to a different HA (aka the Redirected HA) instead 🌸
this behaviour isn't something a legacy HA does, so it isn't in the description below. with a legacy FA, check out Section 4.1 for the specific field in the Registration Request 🧚
- The MN sets the Home Agent address field in the Registration Request to
ALL-ZERO-ONE-ADDR💖 - The MN (if it's using a co-located CoA and registering directly with the HA) or the FA (if the MN is registering through the FA) sends the Registration Request to the "Requested HA". If the MN knows an HA address, it can add that address to the Requested HA Extension in the Registration Request 🍓
- when the HA gets the Registration Request and the HA field is set to
ALL-ZERO-ONE-ADDR, the HA may reject it with Reply codeREDIRECT-HA-REQand suggest an alternate HA 👑
The HA may reject the request for a bunch of reasons, which are outside the scope of this spec. If it rejects the request, the HA field in the Reply is set to this HA's address. The IP address of the HA being redirected to goes in the Redirected HA Extension. That extension is mandatory whenever the reply code is REDIRECT-HA-REQ. The HA then sends the Reply to the FA/MN 🔥
- The FA sends the Reply to the MN 🫶
- If the error code is
REDIRECT-HA-REQ, the MN gets the HA address from the Redirected HA Extension. Then it sends a Registration Request to the Redirected HA. The MN may choose to add the Requested HA Extension to this new Registration Request ✨
If a registration loop happens (that's when the Redirected HA is an HA that already told the MN to register somewhere else), the MN stops sending any more Registration Requests and gives an indication that the loop was detected 🙈 How many consecutive Redirected HAs the MN remembers for loop detection is an implementation parameter 💜
4.2.1. Example with Message Flow Diagram ✨
okay so bestie, Figure 3 walks through one specific example 🦋 where the mobile node is using a FA-located Care-of Address, and the FA is not a legacy FA. Here's the whole flow 👀
MN FA Requested HA Redirected HA
| 1 | | |
|------------>| 2 | |
| |--------------->| |
| | | |
| | | |
| | 3 | |
| 4 |<---------------| |
|<------------| | |
| | | |
| | 5 | |
|--------------------------------------------->|
| | | |
Figure 3: Example Message Flow for HA Redirection- the MN sets the Home Agent address field in the Registration Request to
ALL-ZERO-ONE-ADDR💖. Since this MN is using the FA CoA, it sends the Registration Request to the FA, and the request looks like this:
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| MN | FA | | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+If the MN knows an HA address already, it can drop that address into the Requested HA Extension in the Registration Request as a hint 🎀. That extension isn't shown above.
- the FA sends the Registration Request on to the Requested HA. If the Requested HA Extension is there, the Requested HA is the HA address inside that extension. If the Requested HA Extension is not present, the FA figures out the Requested HA through means outside the scope of this specification 🧚. The request now looks like this:
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA |Requested HA| | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+- the HA processes the Registration Request according to Mobile IPv4 [1] and the messaging defined in this specification 🔥. Now here's the twist: if the registration succeeds, but local configuration, administrative policy, etc. tells the HA to send the MN somewhere else, the HA rejects the request with error code
REDIRECT-HA-REQ😭. It fills in the address of the Redirected HA in the Redirected HA Extension, then sends a Registration Reply reject back to the FA, formatted like so:
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| | Src IP of | | HA |FA CoA |
| HA | the RRQ | | | |
+-----------------------------------------------------------+
| Redirected HA Extension ... |
+-----------------------------------------------------------+- the FA relays the Registration Reply to the MN 💅:
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA | MN | | HA |FA CoA/|
+-----------------------------------------------------------+
| Redirected HA Extension ... |
+-----------------------------------------------------------+- if the MN can authenticate the Reply, it pulls the HA address out of the Redirected HA Extension 🫶. Then it sends a Registration Request to the Redirected HA, unless it has already gotten a redirection response from that HA while processing the Registration Request. The MN may also choose to add a Requested HA Extension to this new Registration Request.
5. Mobility Agent Considerations 🌸
okay so this section is where we get into the nitty-gritty 🤓. It breaks down how each mobility agent behaves, in detail, so grab a snack bestie 🍓.
5.1. Mobile Node Considerations 💜
the mobile node MUST use the NAI extension for home address assignment whenever it uses the messaging mechanism in this document ✨. Since the MN is using the NAI extension, the Home Address field gets set to 0.0.0.0.
while dynamic HA assignment is in progress and the MN hasn't successfully anchored at a home agent yet, the MN MUST set the Home Agent field in the Registration Request to an ALL-ZERO-ONE-ADDR, which is either 255.255.255.255 or 0.0.0.0 🧚.
the Registration Request MUST be protected by a valid authenticator, as specified in Mobile IPv4 [1] or Mobile IPv4 Challenge/Response Extensions [5] 🔐. How you configure security associations is deployment specific, so it's outside the scope of this specification. The security associations between an MN and an individual HA may also be dynamically derived during dynamic HA assignment, based on a shared secret between the MN and AAA infrastructure [7] 🦋.
the mobile node MUST maintain the rest of the Mobile IP session with the Assigned HA 💖.
as mentioned in the Security Considerations (Section 9), there's a possibility of more than one HA creating a mobility binding entry for a given MN 😱. That happens if a rogue node in the middle captures the Registration Request and forwards it to other home agents. The MN can mitigate this by using a short lifetime (e.g., 5 seconds) in the Registration Request with the Home Agent field set to ALL-ZERO-ONE-ADDR 🛡️.
the next sections describe MN behavior in FA CoA mode and co-located CoA mode 💫.
5.1.1. MN Using FA CoA 🎀
when a mobile node starts a Mobile IP session that requests dynamic HA assignment, it MUST set the home agent address field in the Registration Request to ALL-ZERO-ONE-ADDR 🌈. The destination IP address of the Registration Request is the FA. The FA works out the Requested HA and forwards the Registration Request to it. Registration Request processing then happens on the Requested HA, per the specification in this document.
the Registration Request MUST be appropriately authenticated so the HA can validate the request 🔒.
if a successful Registration Reply comes back, the MN gets the Assigned HA from the HA field of the Reply 🎉. The Assigned HA address will be the same as the Requested HA Extension, if the MN included one in the Registration Request.
if a Registration Reply comes back with code REDIRECT-HA-REQ, the MN MUST authenticate the Reply based on the HA address in the HA field of the Reply, then attempt Registration with the HA address given in the Redirected HA Extension 🦄. The MN MUST put that Redirected HA address in the Requested HA Extension of the new Registration Request.
sometimes, for the very first Registration Request, the MN might want to hint to the network that it should anchor at a specific HA. In that case the MN SHOULD put that address in the HA address of the Requested HA Extension 💅.
5.1.2. MN Using Co-Located CoA 🍓
an MN in co-located CoA mode that's requesting dynamic HA assignment MUST set the home agent address field in the Registration Request to ALL-ZERO-ONE-ADDR 🌸. The destination IP address of the Registration Request is the Requested HA. Some ideas on how to pick a Requested HA are briefly covered in Section 6 🧠.
if a successful Reply comes back, the MN gets the Assigned HA address from that successful Registration Reply ✅. The Assigned HA will be the same as the Requested HA that the Registration Request was sent to. The MN MUST cache the Assigned HA address for the length of the Mobile IP session 💾. It then MUST use this cached Assigned HA address as the home agent address in all later Re-Registration and De-Registration Request(s). This makes sure that for the whole Mobile IP session, the mobile node stays anchored to the assigned home agent it first registered with 🧷.
if a Registration Reply comes back with code REDIRECT-HA-REQ, the MN MUST authenticate the Reply based on the HA address in the HA field of the Reply, then attempt Registration with the HA address given in the Redirected HA Extension 🪄. The MN MUST put the Redirected HA in the Requested HA Extension of the new Registration Request.
for the first Registration Request, the MN may want to hint to the network that it should be anchored at a specific HA, and in that case the MN SHOULD put that address in the HA address of the Requested HA Extension 💖.
while requesting dynamic HA assignment and registering directly with an HA, the Requested HA Extension MUST be included, and it MUST contain the address of the HA the Registration Request is sent to 🎯. When the MN uses co-located CoA but registers via a legacy FA, the HA field in the Registration Request may be set to Requested HA 🫧.
if the Registration Request contains the Requested HA Extension, the HA address in that extension MUST match the destination IP of the Request 🔍.
5.1.3. Refreshing Assigned HA Address on Mobile Node 🔄
when the Mobile IP session ends, the mobile node MAY clear the Assigned HA address it cached as the home agent address 🧹. It MAY request a new HA address for the new Mobile IP session by leaving out the Requested HA Extension. The upside of this approach is that the mobile node will always be anchored to an optimal home agent, the one it started the Mobile IP session from ✨.
alternately, the MN may save the Assigned HA address and use it in the Requested HA Extension, along with the ALL-ZERO-ONE-ADDR HA address in the Registration Request, for a new Mobile IP session 🌈.
5.2. Foreign Agent Considerations 🧚♀️
when the mobile node is using an FA CoA, it always registers via the FA 💅. When the MN is using a co-located CoA, it may register through an FA, or it may register directly with an HA. The exception is when the R bit is set in the FA's agent advertisement, in which case the MN always registers through the FA 🙈.
when the FA receives a Registration Request with the HA address field set to ALL-ZERO-ONE-ADDR and no Requested HA Extension, the FA gets the Requested HA address to forward the request using means outside the scope of this specification 🔭. Some ideas on how to pick a Requested HA are briefly covered in Section 6.
if the FA can't get the Requested HA to forward a Registration Request from the MN, it MUST reject the request with error code NONZERO-HA-REQD 💀.
if the MN has included the Requested HA Extension, the FA MUST forward the Registration Request to the address in that extension ✈️. If the HA address in that 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 FA uses that address as the destination for the relayed Registration Request 💌.
backward-compatibility issues related to the mobility agents are covered in Section 10 🦋.
5.3. Home Agent Considerations ✨
okay bestie, so a home agent can handle an incoming Registration Request in one of two ways 🦋
- The MN or FA sends the Registration Request to the Requested HA. "Requested HA" only has meaning inside a Registration Request message 💅. When the Requested HA successfully processes the request, creates a binding, and sends a Reply with its address, it becomes the Assigned HA. "Assigned HA" only has meaning inside a Registration Reply message 🫶.
- A home agent that gets a Registration Request with the HA field set to ALL-ZERO-ONE-ADDR MAY reject it, even if it authenticated successfully, and suggest an alternate HA address in the Reply 🌸. In that case, the HA puts its own address in the HA field of the Reply, sets the Reply code to REDIRECT-HA-REQ, and adds the Redirected HA Extension 🎀.
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 😭 that's a hard no, bestie 🙅♀️
5.3.1. Assigned Home Agent Considerations 🌈
The HA that processes the incoming Registration Request fully in accordance with Mobile IPv4 [1] and this specification becomes the Assigned HA. The Registration Request terminates at the Assigned HA ✨
The Assigned HA creates one mobility binding per MN and sends the Registration Reply to the MN by copying its address into the Home Agent field and using it as the source IP address of the Reply 💖
Here's the cheat sheet for what the Assigned HA does, based on the destination IP address and the Home Agent field of the Registration Request 📋
Dest IP Addr HA field Processing at Assigned HA
------------ ------------ ----------------------------------
Unicast non-unicast Mobile IPv4 [1]: There is no change
in handling for this case from
(Must be Mobile IPv4. It is mentioned here
equal to the for reference only.
HA receiving HA denies the registration with
the RRQ) error code 136 and sets HA field to
its own IP address in the reply as
per Section 3.8.3.2 in [1].
ALL-ZERO- New Behavior: Accept the RRQ as per
ONE-ADDR this specification. Authenticate
the RRQ and create mobility binding
if the HA is acting as Assigned HA.
Set HA field to its own IP address
in the Registration Reply.
OR
New Behavior: If authentication is
successful, reject RRQ with a new
error code REDIRECT-HA-REQ. HA
puts its address in HA address
field of Reject. HA suggests an
alternate HA to use in the new
Redirected HA Extension.
Table 1: Registration Request Handling at Assigned HAAs per the messaging proposed here, the mobile node (or the foreign agent) sends the Registration Request to the Requested HA address, which is a unicast address. Therefore, this document does not specify any new behavior for the case where the HA receives a subnet directed broadcast Registration Request, as described in Section 3.8.2.1 of the Mobile IPv4 specification [1] 🙈 Although the Home Agent field in the Registration Request is not a unicast address, the destination IP address is a unicast address. This avoids the problem associated with a subnet-directed broadcast destination IP address, which may result in multiple HAs responding. Thus, there is no need to deny the registration as stated in Mobile IPv4 [1] Section 3.8.3.2 🧚
When the destination IP address is a unicast address and the Home Agent field is ALL-ZERO-ONE-ADDR, the HA accepts or denies the registration and sets the HA field to its own IP address in the reply. In other words, the registration is not rejected with error code 136 🦋
The HA can reject the request with the error code REDIRECT-HA-REQ and suggest an alternate HA 🔥 This redirection can be used for load balancing, geographical proximity based on Care-of Address, or other reasons. The HA puts its own address in the HA field of the Registration Reply message and puts the address of the redirected HA in the Redirected HA Extension. If the HA accepts the Request, it sets the HA field in the Registration Reply to its own address 💜
The Requested HA always performs standard validity checks on the Registration Request. If there is any error, the Registration Request is rejected with the error codes specified in Mobile IPv4 [1] 🫶
6. Requested Home Agent Selection 👑
When dynamic HA assignment is requested, the MN (or FA, in the case of registration via FA) sends the Registration Request to the Requested HA. This address MUST be a unicast IP address. If the MN has included a Requested HA Extension in the Registration Request, the HA address in that extension is the Requested HA 💖
Here are some examples of ways the MN or the FA can pick the Requested HA, briefly 🌸
DHCP:
The MN performs DHCP to get an IP address on the visited network. The Requested HA is learned from the DHCP Mobile IP Home Agent Option 68 [4]. The MN sends the Registration Request directly to this HA and receives the Assigned HA to use for the rest of the Mobile IP session 🎀
AAA:
The MN performs challenge/response [5] with the FA. The FA retrieves the Requested HA from the AAA server and forwards the Registration Request directly to this HA. The Assigned HA sends a Registration Reply to the FA, which relays it to the MN. The MN uses the Assigned HA for the rest of the Mobile IP session 🔐
DNS:
In this case, the hostname of the HA is configured on the MN or obtained by some other means, e.g., using a service location protocol. The MN performs a DNS lookup on the HA hostname. The DNS infrastructure provides a resource record with information to identify the optimal HA to the MN. The MN sends a Registration Request directly to the HA and receives the Assigned HA to use for the rest of the Mobile IP session 🌐
Static configuration:
The HA address is statically configured on the MN. The MN sends the Registration Request to the configured address. The Requested HA may then redirect the MN to a Redirected HA 🧸
7. Error Values 🍓
Each entry in the following table contains the name and value of the error code to be returned in a Registration Reply. It also includes the section in which the error code is first mentioned in this document 📝
Error Name Value Section Description
--------------- ----- ------- -----------------------------
NONZERO-HA-REQD 90 5.2 Non-zero HA address required
in Registration Request.
REDIRECT-HA-REQ 143 5.3 Re-register with redirected HA.8. IANA Considerations 🌈
The code value NONZERO-HA-REQD is a Mobile IP response code [1] taken from the range of values associated with rejection by the foreign agent (i.e., a value in the range 64-127) 🦋
The code value REDIRECT-HA-REQ is a Mobile IP response code [1] taken from the range of values associated with rejection by the home agent (i.e., a value in the range 128-192) 🧚
The Dynamic HA Extension is assigned from the range of values associated with skippable extensions at the home agent (i.e., a value in the range 128-255) ✨
IANA has recorded the values as defined in Sections 7 and 3.4 💅
9. Security Considerations 🔥
This is the serious part, bestie, so pay attention 🙏 This specification assumes that a security configuration has been preconfigured between the MN and the HA, or is configured along with the initial Registration Request and Registration Reply as per [7].
There is a possibility of more than one HA creating a mobility binding entry for a given MN, if a man in the middle captures the Registration Request with the HA field set to ALL-ZERO-ONE-ADDR and forwards it to other HAs. This scenario assumes that the rogue node can find out the addresses of the HAs that are able to authenticate the Registration Request. It also assumes that the rogue node has the capability to store, duplicate, and send packets to the other HAs within the limited time of the replay window. Otherwise, these HAs will reject the Registration Requests anyway. In addition, this type of attack is only possible when the Requested HA Extension is not included in the registration message. The mobile node can minimize the duration of this condition by using a short lifetime (e.g., 5 seconds) in the Registration Request 😱
This specification does not change the security model established in Mobile IPv4 [1]. Mobile nodes are often connected to the network via wireless links, which may be more prone to passive eavesdropping or replay attacks. Such an attack might lead to bogus registrations, redirection of traffic, or denial of service 🚨
As per the messaging in this document, the Assigned Home Agent will process the incoming Registration Request as per Mobile IPv4 [1]. Hence, the Assigned Home Agent will have the same security concerns as those of the home agent in Mobile IPv4 [1]. They are addressed in Section 5, "Security Considerations", of Mobile IPv4 [1] 🛡️
The Registration Request and Registration Reply messages are protected by a valid authenticator as specified in Mobile IPv4 [1]. Configuring security associations is a deployment-specific issue and is covered by other Mobile IP specifications. There can be many ways of configuring security associations, but this specification does not require any specific way 🔑
An example is where the security association between an MN and an individual HA (Requested or Assigned) is dynamically derived during the registration process, based on a shared secret between the MN and AAA infrastructure, as defined in [7]. The Registration Request is protected with the MN-AAA Authentication Extension, and the Registration Reply is protected with the MN-HA Authentication Extension. Because the security association is shared between the MN and AAA, any dynamically assigned HA in the local domain can proxy authenticate the MN using AAA as per [7] 🌸
The Assigned Home Agent authenticates each Registration Request from the mobile node as specified in Mobile IPv4 [1] and/or RFC 3012. The MN also authenticates the Registration Reply from the Assigned HA, so the existing trust model in Mobile IPv4 [1] is maintained 💜
10. Backward-Compatibility Considerations 🧚
Okay bestie, time for the mixed-crowd drama 🫶 This part is about what happens when this spec is in a mixed environment, where some nodes implement it and some don't. Each example looks at one "legacy" node hanging out with nodes that do. 💅
Legacy Home Agent:
Legacy home agents may reject the Registration Request with error code 136 because the Home Agent field is not a unicast address. However, some legacy HA implementations may coincidentally process the Registration Request in accordance with this document, when the HA field in Registration Request is set to ALL-ZERO-ONE-ADDR. 🙈
Legacy Foreign Agent:
Legacy foreign agents may forward a Registration Request with home agent field set to ALL-ZERO-ONE-ADDR by setting the destination IP address to ALL-ZERO-ONE-ADDR. This will result in the packet being dropped or incidentally handled by a next-hop HA, adjacent to the FA. The MN may not be aware of the dropped Registration Request and may probably retry registration, thereby increasing the delay in registration. 😭
To reduce that delay, the MN should take the following steps:
- The MN should send the Registration Request as specified in this specification. In other words, the MN should set the Home Agent field in the Registration Request to
ALL-ZERO-ONE-ADDRand also add the Requested HA Extension. ✨ - If the MN does not receive a Registration Reply within some time and/or after sending a few Registration Requests, it can assume that the Registration Request(s) has been dropped, either by a legacy FA or an incorrect HA. In addition, if the registration is denied with error code 70 (poorly formed Request), the MN can assume that the legacy FA cannot process this message. In either case, the MN should fall back to a recovery mechanism. The MN should quickly send a new Registration Request as mentioned in Section 4.1 step 2. This step will ensure that a legacy FA will forward the Registration Request to the home agent, thereby making dynamic HA assignment possible. 🔥
Legacy Mobile Node:
An MN that sends a Registration Request to an FA that can do dynamic HA assignment, but does not set the HA field to ALL-ZERO-ONE-ADDR, will continue to be registered with its statically configured HA, exactly according to RFC 3344. 🎀
11. Acknowledgements 🌸
The authors would like to thank Pete McCann for thorough review, suggestions on security considerations, and definition of ALL-ZERO-ONE-ADDR. Thanks to Kuntal Chowdhury for extensive review and comments on this document. Also thanks to Henrik Levkowetz for detailed reviews and suggestions. Thomas Narten highlighted issues for legacy FA considerations. Thanks to Ahmad Muhanna for pointing out the scenario of multiple bindings on HAs, documented in the Security Considerations section. 👑
The authors would like to thank Mike Andrews, Madhavi Chandra, and Yoshi Tsuda for their review and suggestions. 🫶
12. Normative References 📚
- [1] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
- [2] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
- [3] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999.
- [4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
- [5] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response Extensions", RFC 3012, November 2000.
- [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [7] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, March 2005.
Authors' Addresses 🦋
Milind Kulkarni
Cisco Systems Inc.
170 W. Tasman Drive,
San Jose, CA 95134
USA
Phone: +1 408-527-8382
EMail: mkulkarn@cisco.comAlpesh Patel
Cisco Systems Inc.
170 W. Tasman Drive,
San Jose, CA 95134
USA
Phone: +1 408-853-9580
EMail: alpesh@cisco.comKent Leung
Cisco Systems Inc.
170 W. Tasman Drive,
San Jose, CA 95134
USA
Phone: +1 408-526-5030
EMail: kleung@cisco.comFull Copyright Statement ⭐
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 💜
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🌈
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). ✨
📦 where this page comes from
- ietf: rfc4433 2006-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms