Request for Comments: 4433 A. Patel
Category: Standards Track K. Leung
Cisco Systems Inc.
March 2006
Mobile IPv4 Dynamic Home Agent (HA) Assignment
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
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 document proposes a messaging
mechanism for dynamic home agent assignment and HA redirection. The
goal is to provide a mechanism to assign an optimal HA for a Mobile
IP session while 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 ..........................................23
1. Introduction
This document 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.
The MN requests a dynamically assigned HA by setting 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 a successful
Registration Reply containing the HA’s own address. The requested HA
can suggest an alternate HA and if so, the Registration Reply is
rejected with a new error code REDIRECT-HA-REQ and the alternate HA
address is specified in a new extension (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 a hint to the network about the MN’s
preferred HA.
The messaging mechanism is defined in this document so that the MN
can request and receive a dynamic HA address in Mobile IP messages.
However, the mechanism by which the network selects an HA for
assignment to the MN is outside the scope of this document. For
example, the selection may be made by any network node that receives
the Registration Request (or information about the Registration
Request), such as a Foreign Agent, AAA server, or home agent. The
node that selects the HA may select one based on a number 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. In addition, the following terms are used:
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 concept of
identifying an MN by the NAI and enabling dynamic home address
assignment. When the home address is dynamically assigned, it is
desirable to discover the home agent dynamically or inform the MN
about an optimal HA to use for a multitude 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 such a case, the MN will be anchored
to its distant home agent, resulting in tunneled traffic traveling
a long distance between home agent and the mobile node. When a
Mobile IP session initiates, if the mobile node can be assigned a
home agent that is close to the mobile node it can drastically
reduce the latency between the home agent and mobile node.
- In a large-scale Mobile IP deployment, it is cumbersome to
provision MNs with multiple HA addresses.
- It is desirable to achieve some form of load balancing between
multiple HAs in the network. Dynamic HA assignment and/or HA
redirection lets the network select the optimal HA from among a set
of HAs and thus achieve load balancing among a group of HAs.
- Local administrative policies.
3.1. Scope
This specification does not address the problem of distributing a
security association between the MN and HA, and it can either be
statically preconfigured or dynamically distributed using other
mechanisms [7].
The document introduces the terms Requested/Assigned/Redirected HA
(Section 6). The discovery of candidate HA addresses for insertion
into the Redirected HA Extension can be accomplished through various
means that are network and/or deployment specific and hence are
outside the scope of this specification.
The MN MAY request dynamic HA assignment when it is not aware of any
HA address and even when it is aware of at least one HA address.
3.2. Dynamic Home Agent Discovery in Mobile IPv4
Mobile IPv4 [1] specifies the mechanism for discovering the mobile
node’s home agent using subnet-directed broadcast IP address in the
home agent field of the Registration Request. This mechanism was
designed for mobile nodes with a static home address and subnet
prefix, anchored on fixed home network. However, using subnet-
directed broadcast as the destination IP address of the Registration
Request, it is unlikely that the Registration Request will 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].
3.3. NAI Usage and Dynamic HA Assignment
The Mobile IPv4 NAI Extension for IPv4 [2] introduced the concept of
identifying an MN by the NAI and enabling dynamic home address
assignment. This document requires that while using dynamic HA
assignment, MN MUST use the NAI and obtain a home address. MN can
still suggest a static home address in the Registration Request, but
must 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. This is a generic extension and can be used in Registration
Request and Reply messages. It is 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 Extension
Type DYNAMIC-HA-ADDRESS (skippable) 139 is the type,
which specifies the dynamic HA address.
Subtype Defines the use of this extension as:
subtype 1 = Requested HA Extension
2 = Redirected HA Extension
Length Indicates the length of the extension not
including the type, subtype, and length fields.
Length is always 4 bytes.
HA-Address Address of the home agent.
3.4.1. Requested HA Extension
The Requested HA Extension is a Dynamic HA Extension of subtype 1.
The MN may include the Requested HA Extension in the Registration
Request as a hint to the network where it wishes to be anchored.
This extension contains the address of the HA. A valid unicast IP
address MUST be used as HA address in this extension.
In absence of an FA, the Registration Request is forwarded to this
HA. In presence of an FA, the FA MUST forward the Registration
Request to the HA address in this extension.
3.4.2. Redirected HA Extension
The Redirected HA Extension is a Dynamic HA Extension of subtype 2.
The Redirected HA Extension contains the address of the HA where the
MN should attempt the next registration. The HA receiving a
Registration Request can suggest an alternate HA and, if so, the
Registration Reply is sent with a new error code REDIRECT-HA-REQ and
the alternate HA address is specified in this extension.
The Redirected HA Extension MUST be included in Registration Reply
when the reply code is REDIRECT-HA-REQ.
4. Messaging Mechanism for Dynamic HA Assignment/Redirection
This specification presents two alternatives for home agent
assignment:
(a) Dynamic HA assignment (described in Section 4.1) and
(b) HA redirection (described in Section 4.2).
4.1. Messaging for Dynamic HA Assignment
The following sequence of events occurs when the MN requests dynamic
home agent assignment:
1. The MN sets the Home Agent address field in the Registration
Request to ALL-ZERO-ONE-ADDR. If the MN is aware of a desired HA
address, it can add that address in the Requested HA Extension in
the Registration Request. If the HA does not support the
Requested HA Extension, see step 2 below.
2. This step is applicable, in lieu of step 1, for an MN that is
aware of the HA address and desires dynamic HA assignment. Also,
the MN follows this (when aware of a HA address) when it
discovers a legacy FA in the path or if the known HA does not
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 setting it to ALL-ZERO-
ONE-ADDR). The MN also adds the same HA address in the Requested
HA Extension in the Registration Request.
3. The MN (if using co-located CoA and registering directly with the
HA) or the FA (if the MN is registering via the FA) sends the
Registration Request to the "Requested HA". If the Requested HA
Extension is present, Requested HA is specified in the "HA
Address" of this extension.
Per Section 10, in case of a legacy FA, legacy FA forwards the
Registration Request to the address in the HA field of the
request (thus, MN uses step 2 above in case of legacy FA instead
of step 1).
4. The "Requested HA" is the home agent that processes the
Registration Request in accordance with Mobile IPv4 [1] and as
per the specification in this document. It creates mobility
binding for a successful Registration Request. It also sends a
Registration Reply to the MN.
5. The MN obtains an "Assigned HA" address from the HA field in the
successful Registration Reply and uses it for the remainder of
the session. (Note that the "Assigned HA" will be the same as
the "Requested HA".)
6. Subsequent Registration Request messages for renewal are sent to
the Assigned HA.
Section 5.3.1 describes the Assigned HA in detail. Some ideas on how
to select the Requested HA are briefly covered in Section 6.
4.1.1. Example with Message Flow Diagram
Detailed explanation of this alternative is best described with the
help of a message flow diagram and description.
Figure 2 shows one specific example of a mobile node using an
FA-located Care-of Address (FA CoA) and FA understands the Requested
HA Extension per this specification.
Other scenarios such as when the mobile node uses a co-located care
of address and presence of a legacy HA or FA are not described below,
but the behavior is similar.
MN FA Requested/Assigned HA
| 1 | |
|------------>| 2 |
| |--------------->|
| | |
| | |
| | 3 |
| 4 |<---------------|
|<------------| |
| | |
| | 5 |
|----------------------------->|
| | |
Figure 2: Example Message Flow for Dynamic HA Assignment
1. The MN sets the Home Agent address field in the Registration
Request to ALL-ZERO-ONE-ADDR. Since the MN is using FA CoA in
this example, it sends the Registration Request to the FA. The
Registration Request is formatted as follows:
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| MN | FA | | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+
If the MN is aware of a desired HA address, it can add that
address in the Requested HA Extension in Registration Request as
a hint. That extension is not shown above.
2. The FA sends the Registration Request to the Requested HA. If
the Requested HA Extension is present, Requested HA is the HA
address in this extension. If the Requested HA Extension is not
present, the FA determines the Requested HA through means outside
the scope of this specification. The Registration Request is
formatted as follows:
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA |Requested HA| | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+
(If MN includes the Requested HA Extension, the FA copies that
extension. The FA then forwards the Registration Request, along
with the Requested HA Extension, to the HA address specified in
Requested HA Extension.)
3. The HA processes the Registration Request in accordance with
Mobile IPv4 [1] and the messaging defined in this document. The
HA creates mobility binding for successful request and becomes
the Assigned HA. The HA then sends a Registration Reply to the
FA, which is formatted as follows:
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
|Assigned| Src IP of | | Assigned HA |FA CoA/|
| HA | the RRQ | | | |
+-----------------------------------------------------------+
4. The FA relays the Registration Reply to the MN, as follows:
+-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA | MN | | Assigned HA |FA CoA/|
+-----------------------------------------------------------+
5. The MN obtains the Assigned HA address from the HA field in the
successful Registration Reply and uses it for the remainder of
the session. The MN sends subsequent Re-Registration or
De-Registration Requests for the remainder session directly to
the Assigned HA. The Home Agent address field in this
Registration Request is set to ALL-ZERO-ONE-ADDR. Note that the
Assigned HA is the same as the Requested HA.
4.2. Messaging for HA Redirection
This section describes the events that occur when the Requested
HA does not accept the Registration Request and redirects the
mobile node to another HA (aka Redirected HA) instead. This
behavior is not exhibited by a legacy HA and so is not referred
in the description below. In presence of a legacy FA, please
refer to Section 4.1 for the specific field in the Registration
Request.
1. The MN sets the Home Agent address field in the Registration
Request to ALL-ZERO-ONE-ADDR.
2. The MN (if using co-located CoA and registering directly with the
HA) or FA (if the MN is registering via the FA) sends the
Registration Request to the "Requested HA". If the MN is aware
of an HA address, it can add that address in the Requested HA
Extension in the Registration Request.
3. When the HA receives the Registration Request, if the HA field is
set to ALL-ZERO-ONE-ADDR, the HA may reject the request with
Reply code REDIRECT-HA-REQ and suggest an alternate HA.
The HA may reject the request for a number of reasons, which are
outside the scope of this specification. If the HA rejects the
Request, the HA field in the Reply is set to this HA’s address.
The IP address of the HA that is the target of the redirection is