draft-ietf-mip4-dynamic-assignment-01.txt   draft-ietf-mip4-dynamic-assignment-02.txt 
Mobile IP Working Group Milind Kulkarni Mobile IP Working Group Milind Kulkarni
INTERNET-DRAFT Alpesh Patel INTERNET-DRAFT Alpesh Patel
Category: Standards Track Kent Leung Category: Standards Track Kent Leung
Date : 28 April 2004 Cisco Systems Inc. Date : 28 June 2004 Cisco Systems Inc.
Mobile IPv4 Dynamic Home Agent Assignment Mobile IPv4 Dynamic Home Agent Assignment
draft-ietf-mip4-dynamic-assignment-01.txt draft-ietf-mip4-dynamic-assignment-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance By submitting this Internet-Draft, I certify that any applicable
with all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance
with RFC 3668.
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet Engineering
Engineering Task Force (IETF), its areas, and its working Task Force (IETF), its areas, and its working groups. Note that
groups. Note that other groups may also distribute working other groups may also distribute working documents as Internet-
documents as Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet Drafts
Drafts as reference material or to cite them other than as "work as reference material or to cite them other than as "work in
in progress." progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 28, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
Mobile IP (RFC 3344) uses the Home Agent (HA) to anchor Mobile IPv4 [1] uses the Home Agent (HA) to anchor sessions of a
sessions of a roaming Mobile Node (MN). This draft proposes a roaming Mobile Node (MN). This draft proposes a messaging mechanism
messaging mechanism for dynamic home agent assignment and HA for dynamic home agent assignment and HA redirection. The goal is
redirection. The goal is to provide a mechanism to assign an to provide a mechanism to assign an optimal HA for a Mobile IP
optimal HA for a Mobile IP session while allowing any suitable session while allowing any suitable method for HA selection.
method for HA selection.
Table of Contents Table of Contents
1. Introduction.....................................................2 1. Introduction.................................................3
2. Terminology.......................................................3 2. Requirements Terminology.....................................3
3. Problem Statement.................................................4 3. Problem Statement............................................4
3.1 Scope............................................................5 3.1 Scope.......................................................5
3.2 Dynamic Home Agent Discovery in RFC 3344.........................5 3.2 Dynamic Home Agent Discovery in Mobile IPv4.................5
3.3 NAI usage and dynamic HA assignment..............................5 3.3 NAI usage and dynamic HA assignment.........................5
3.4 Dynamic HA extension.............................................5 3.4 Dynamic HA extension........................................6
3.4.1 Redirected HA extension........................................6 3.4.1 Requested HA extension....................................6
3.4.2 Requested HA extension.........................................6 3.4.2 Redirected HA extension...................................7
4. Messaging mechanism for dynamic HA assignment/redirection.........7 4. Messaging mechanism for dynamic HA assignment/redirection....7
4.1 Messaging for dynamic HA assignment..............................7 4.1 Messaging for dynamic HA assignment.........................7
4.1.1 Example with Message Flow Diagram..............................7 4.1.1 Example with Message Flow Diagram.........................8
4.2 Messaging for HA redirection.....................................9 4.2 Messaging for HA redirection................................9
4.2.1 Example with Message Flow Diagram.............................10 4.2.1 Example with Message Flow Diagram........................10
5. Mobility Agent Considerations for dynamic HA assignment..........11 5. Mobility Agent Considerations...............................12
5.1 Mobile Node Considerations......................................11 5.1 Mobile Node Considerations.................................12
5.1.1 MN using FA CoA...............................................12 5.1.1 MN using FA CoA..........................................12
5.1.2 MN using Collocated CoA.......................................12 5.1.2 MN using Collocated CoA..................................13
5.1.3 Refreshing Assigned HA Address on Mobile Node.................13 5.1.3 Refreshing Assigned HA Address on Mobile Node............13
5.2 Foreign Agent Considerations....................................13 5.2 Foreign Agent Considerations...............................14
5.3 Home Agent Considerations.......................................13 5.3 Home Agent Considerations..................................14
5.3.1 Assigned Home Agent Considerations............................14 5.3.1 Assigned Home Agent Considerations.......................15
6. Requested Home Agent Selection...................................16 6. Requested Home Agent Selection..............................16
7. Error Values.....................................................17 7. Error Values................................................17
8. IANA Considerations..............................................17 8. IANA Considerations.........................................17
9. Security Considerations..........................................17 9. Security Considerations.....................................18
9.1 Message Authentication Codes....................................17 10. Backward Compatibility Considerations......................19
9.2 Areas of Security Concern in this Protocol......................18 11. Change Log from previous versions..........................19
10. Backward Compatibility Considerations...........................18 12. Acknowledgements...........................................20
11. Change Log from previous version................................19 13. Normative References.......................................20
12. Intellectual Property Rights....................................19 Authors' Addresses.............................................20
13. Acknowledgements................................................19 Intellectual Property Statement................................21
14. References......................................................19
Authors' Addresses..................................................20
Full Copyright Statement............................................20
Intellectual Property...............................................21
Acknowledgement.....................................................21
1. Introduction 1. Introduction
This document adds to the Mobile IP protocol [1], by proposing This document adds to the Mobile IP protocol [1], by proposing a
a messaging mechanism for dynamic home agent assignment and messaging mechanism for dynamic home agent assignment and home
home agent redirection during initial registration. The goal is agent redirection during initial registration. The goal is to
to assign an optimal HA for a Mobile IP session. The mobile assign an optimal HA for a Mobile IP session. The mobile node MUST
node MUST use Network Access Identifier (NAI) extension for use Network Access Identifier (NAI) extension [2] when requesting a
home address assignment. dynamically assigned HA.
MN requests the network to dynamically assign an HA by setting MN requests a dynamically assigned HA by setting the HA field in
HA field to ALL-ZERO-ONE-ADDR (defined in next section) in the initial Registration Request to ALL-ZERO-ONE-ADDR (defined in
initial Registration Request. If the request is accepted, the section 2). If the request is accepted, the HA field in successful
HA field in successful Registration Reply contains the HA Registration Reply contains the HA address. The requested HA can
address. The requested HA can suggest an alternate HA and if suggest an alternate HA and if so, the Registration Reply is
so, the Registration Reply is rejected with a new error code rejected with a new error code (REDIRECT-HA-REQ) and the alternate
(REDIRECT-HA-REQ) and the alternate HA address is specified in HA address is specified in a new extension (Redirected HA
a new extension (Redirected HA extension). extension).
If the RRQ is rejected with Redirected HA extension or if the If the RRQ is rejected with Redirected HA extension or if the MN
MN wishes to register at a specific HA, MN can put the HA wishes to register at a specific HA, MN can put the HA address in
address in the Requested HA extension in Registration Request. the Requested HA extension in Registration Request. The HA address
The HA address in Requested HA extension is a hint to the in Requested HA extension is a hint to the network where the MN may
network where the MN may be anchored. The HA field is set to be anchored. The HA field is set to ALL-ZERO-ONE-ADDRESS for
ALL-ZERO-ONE-ADDRESS for dynamic HA assignment. dynamic HA assignment.
The messaging mechanism proposed here is generic and can be The messaging mechanism is defined in this document so that the
used as a common foundation to facilitate dynamic HA assignment MN can request and receive a dynamic HA address in Mobile IP
using any suitable method. No specific method is either messages. However, the mechanism by which the network selects
mandated or suggested. The HA receiving Registration Request an HA for assignment to the MN is outside the scope of this
may suggest an alternate HA (HA redirection) for a number of document. For example, the selection may be made by any
reasons; including but not limited to HA load-balancing, network node that receives the registration request (or
geographical proximity, administrative policy etc. 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. Terminology 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 ALL-ZERO-ONE-ADDR: IP address 0.0.0.0 or 255.255.255.255. An
address of 255.255.255.255 would indicate address of 255.255.255.255 would indicate
assigning HA in home domain. An address of assigning HA in home domain. An address of
0.0.0.0 would mean MN just needs a dynamic 0.0.0.0 would mean MN just needs a dynamic
HA, it does not care whether in home or HA, it does not care whether in home or visited
visited domain. domain.
Requested HA: Destination IP address of Home Agent that the Requested HA: Destination IP address of Home Agent that the
first Registration Request is sent to. Must first Registration Request is sent to. Must be
be a unicast IP address. This address can be a unicast IP address. This address can be
obtained as described in section 5.4. obtained as described in section 6.
Assigned HA: If registration is successful, this Home Assigned HA: If registration is successful, this Home Agent
Agent address field is obtained from address field is obtained from successful
successful Registration Reply. Registration Reply.
Redirected HA: If the registration is rejected with error Redirected HA: If the registration is rejected with error code
code (REDIRECT-HA-REQ), the HA being referred (REDIRECT-HA-REQ), the HA being referred to is
to is specified in a new extension specified in a new extension (Redirected HA
(Redirected HA extension). extension).
AAA server: Authentication, Authorization and Accounting AAA server: Authentication, Authorization and Accounting
Server. Server.
DNS: Domain Name Service. DNS: Domain Name System.
DHCP: Dynamic Host Configuration Protocol. DHCP: Dynamic Host Configuration Protocol.
MN: Mobile Node as defined in RFC 3344. MN: Mobile Node as defined in Mobile IPv4 [1].
HA: Home Agent as defined in RFC 3344. HA: Home Agent as defined in Mobile IPv4 [1].
FA: Foreign Agent as defined in RFC 3344. FA: Foreign Agent as defined in Mobile IPv4 [1].
CoA: Care of Address. CoA: Care of Address.
CCoA: Collocated Care of Address. CCoA: Collocated Care of Address.
MN HoA: Mobile Node's Home Address. MN HoA: Mobile Node's Home Address.
NAI: Network Access Identifier [2]. NAI: Network Access Identifier [2].
Src IP: Source IP address of the packet. Src IP: Source IP address of the packet.
Dest IP: Destination IP address of the packet. Dest IP: Destination IP address of the packet.
3. Problem Statement 3. Problem Statement
Mobile IPv4 NAI Extension for IPv4 [2] introduced the concept Mobile IPv4 NAI Extension for IPv4 [2] introduced the concept of
of identifying a MN by the NAI and enabling dynamic home identifying a MN by the NAI and enabling dynamic home address
address assignment. When the home address is dynamically assignment. When the home address is dynamically assigned, it is
assigned, it is desirable to discover the Home Agent desirable to discover the Home Agent dynamically or inform the MN
dynamically or inform the MN about an optimal HA to use for a about an optimal HA to use for a multitude of reasons, such as:
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, which is close to the mobile
node, it can drastically reduce the latency between the home
agent and mobile node.
- Also, in a large scale Mobile IP deployment, it is cumbersome - If the distance between the visited network and the home network
to provision MNs with multiple HA addresses. 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.
- It is desirable to achieve some form of load balancing - In a large scale Mobile IP deployment, it is cumbersome to
between multiple HAs in the network. Dynamic HA assignment provision MNs with multiple HA addresses.
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 is yet another reason for - It is desirable to achieve some form of load balancing between
dynamic HA assignment/HA redirection during the start of a multiple HAs in the network. Dynamic HA assignment and/or HA
Mobile IP session. redirection lets the network select the optimal HA from among a set
of HAs and thus achieve load balancing among a group of HAs.
- The problem of discovering a Mobile node’s HA address is - Local administrative policies.
acknowledged in the MIPv6 working group as part of [8].
3.1 Scope 3.1 Scope
This specification assumes that the Mobile Node and Assigned This specification does not address the problem of distributing a
Home Agent are in the same administrative domain. The scenario security association between the MN and HA, and it can either be
where the Mobile Node and its anchoring Assigned Home Agent are statically preconfigured or dynamically distributed using other
in different administrative domain is beyond the scope of this mechanisms [7].
specification.
The draft introduces the terms Requested/Assigned/Redirected HA The draft introduces the terms Requested/Assigned/Redirected HA
(section 5.4). These terms are merely HA addresses and used (section 6). The discovery of Requested/Assigned/Redirected HA can
depending upon the direction of the registration request or be done by various means, which are network and/or deployment
reply. The discovery of Requested/Assigned/Redirected HA can be
done by various means, which are network and/or deployment
specific and hence this discovery/assignment of specific and hence this discovery/assignment of
Requested/Assigned/Redirected HA is kept outside the scope of Requested/Assigned/Redirected HA is kept outside the scope of this
this specification. specification.
3.2 Dynamic Home Agent Discovery in RFC 3344 3.2 Dynamic Home Agent Discovery in Mobile IPv4
Mobile IP RFC 3344 specifies the mechanism for discovering the Mobile IPv4 [1] specifies the mechanism for discovering the mobile
mobile node's home agent using subnet-directed broadcast IP node's home agent using subnet-directed broadcast IP address in the
address in the home agent field of the Registration Request. home agent field of the Registration Request. This mechanism was
This mechanism was designed for mobile nodes with a static home designed for mobile nodes with a static home address and subnet
address and subnet prefix, anchored on fixed home network. But prefix, anchored on fixed home network. But using subnet-directed
using subnet-directed broadcast as the destination IP address broadcast as the destination IP address of the Registration
of the Registration Request, it is unlikely that the Request, it is unlikely that the Registration Request will reach
Registration Request will reach the home subnet because routers the home subnet because routers will drop these packets by default.
will drop these packets by default. See CERT Advisory CA-1998- See CERT Advisory CA-1998-01 Smurf IP Denial-of-Service Attacks
01 Smurf IP Denial-of-Service Attacks [3]. [3].
3.3 NAI usage and dynamic HA assignment 3.3 NAI usage and dynamic HA assignment
Mobile IPv4 NAI Extension for IPv4 [2] introduced the concept Mobile IPv4 NAI Extension for IPv4 [2] introduced the
of identifying a MN by the NAI and enabling dynamic home concept of identifying a MN by the NAI and enabling dynamic
address assignment. This document mandates that while using home address assignment. This document mandates that while
dynamic HA assignment, MN MUST use NAI and obtain a home using dynamic HA assignment, MN MUST use NAI and obtain a home
address. MN can still suggest a static home address in address. MN can still suggest a static home address in Registration
Registration Request, but must take the address in Registration Request, but must take the address in Registration Reply as the
Reply as the home address for the session. This reference to home address for the session. This is compatible with the
obtaining home address using NAI is as per [2]. procedures documented in the NAI specification [2].
3.4 Dynamic HA extension 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 The Dynamic HA extension, shown in figure 1, contains the address
in Registration Request and Reply messages. It is a skippable of the HA. This is a generic extension and can be used in
Registration Request and Reply messages. It is a skippable
extension. extension.
0 1 2 3 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 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 | | Type | Sub-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA-Address... | HA-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Dynamic HA address Extension Figure 1: The Dynamic HA address Extension
Type DYNAMIC-HA-ADDRESS (skippable) [1] (to be Type DYNAMIC-HA-ADDRESS (skippable) (to be assigned
assigned by IANA) is the type, which specifies the by IANA) is the type, which specifies the
dynamic HA address. dynamic HA address.
Sub-Type is a unique number given to each member in the Sub-Type Defines the use of this extension as:
aggregated type. sub-type 1 = Requested HA extension
2 = Redirected HA extension
Length Indicates the length of the extension not including Length Indicates the length of the extension not
the type, sub-type and length fields. including the type, sub-type and length fields.
Length is always 4 bytes.
HA-Address The address of HA HA-Address Address of the Home Agent.
3.4.1 Redirected HA extension 3.4.1 Requested HA extension
The format of the Redirected HA extension is as defined in The Requested HA extension is a Dynamic HA extension of subtype 1.
section 3.4. This extension uses the subtype value of 1. This
extension has the length field set to 4.
The Redirected HA extension, contains the address of the HA MN may include the Requested HA extension in the registration
where the MN should attempt the next registration. The HA request as a hint to the network where it wishes to be anchored.
receiving a Registration Request can suggest an alternate HA This extension contains the address of the HA. A valid unicast IP
and if so, the Registration Reply is rejected with a new error address MUST be used as HA address in this extension.
code (REDIRECT-HA-REQ) and the alternate HA address is
specified in this extension.
It MUST be included in Registration Reply when the reply code In absence of an FA, the RRQ is forwarded to this HA. In presence
is REDIRECT-HA-REQ. of an FA, FA MUST forward RRQ to the HA address in this extension.
3.4.2 Requested HA extension 3.4.2 Redirected HA extension
The format of the Requested HA address extension is as defined
in section 3.4. This extension uses the subtype value of 2.
This extension has the length field set to 4.
MN may include the Requested HA extension in the registration The Redirected HA extension is a Dynamic HA extension of subtype 2.
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 RRQ is forwarded to this HA. In The Redirected HA extension, contains the address of the HA where
presence of an FA, FA MUST forward RRQ to the HA address in the MN should attempt the next registration. The HA receiving a
this extension. Registration Request 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 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 4. Messaging mechanism for dynamic HA assignment/redirection
4.1 Messaging for dynamic HA assignment This specification presents two alternatives for home agent
assignment. The two alternatives are:
(a) Dynamic HA assignment (described in section 4.1) and
(b) HA redirection (described in section 4.2).
1. MN sets the Home Agent address field in the Registration 4.1 Messaging for dynamic HA assignment
Request to ALL-ZERO-ONE-ADDR.
If the MN is aware of an HA address, it can add that The following sequence of events occurs when the Requested HA
address in the Requested HA extension in Registration accepts the Registration Request and returns a Registration Reply
Request. to the mobile node.
2. The MN (if using collocated CoA) or FA (if using FA CoA)
sends the Registration Request to the "Requested HA".
If the Requested HA extension is present, Requested HA is 1. MN sets the Home Agent address field in the Registration
the HA address in this extension. Request to ALL-ZERO-ONE-ADDR. If the MN is aware of the HA
address, it can add that address in the Requested HA extension
in Registration Request.
2. The MN (if using collocated CoA) or FA (if using FA CoA) 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.
3. "Requested HA" is the home agent, which processes the 3. "Requested HA" is the home agent, which processes the
Registration Request in accordance with RFC 3344 and as Registration Request in accordance with Mobile IPv4 [1] and as
per the specification in this document. It creates per the specification in this document. It creates mobility
mobility binding for successful Registration Request. It binding for successful Registration Request. It also sends
also sends Registration Reply to the MN. Registration Reply to the MN.
4. The MN obtains an "Assigned HA" address from the HA field 4. The MN obtains an "Assigned HA" address from the HA field in
in the successful Registration Reply and uses it for the the successful Registration Reply and uses it for the remainder
remainder of the session. of the session. (Note that the "Assigned HA" will be same as
5. Subsequent Registration Request messages for renewal are the "Requested HA").
sent to the Assigned HA. 5. Subsequent Registration Request messages for renewal are sent
to the Assigned HA.
Section 5.3.1 describes the Assigned HA in detail. Some ideas Section 5.3.1 describes the Assigned HA in detail. Some ideas on
on how to select the Requested HA are briefly covered in how to select the Requested HA are briefly covered in section 6.
section 6.
4.1.1 Example with Message Flow Diagram 4.1.1 Example with Message Flow Diagram
Detailed explanation of this specification is best described Detailed explanation of this alternative is best described with the
with the help of a railroad diagram and description. help of a message flow diagram and description.
Figure 2 shows one specific example of a Mobile Node using FA Figure 2 shows one specific example of a Mobile Node using FA Care
Care of Address. of Address.
Other scenarios such as mobile node using collocated care of Other scenarios such as mobile node using collocated care of
address are not described below, but the behavior is similar. address are not described below, but the behavior is similar.
MN FA Requested/Assigned HA MN FA Requested/Assigned HA
| 1 | | | 1 | |
|------------>| 2 | |------------>| 2 |
| |--------------->| | |--------------->|
| | | | | |
| | | | | |
| | 3 | | | 3 |
| 4 |<---------------| | 4 |<---------------|
|<------------| | |<------------| |
| | | | | |
| | 5 | | | 5 |
|----------------------------->| |----------------------------->|
| | | | | |
Figure 2: Example of Message flows for the specification Figure 2: Example of message flows for dynamic HA assignment
1. MN sets the Home Agent address field in the Registration 1. MN sets the Home Agent address field in the Registration Request
Request to ALL-ZERO-ONE-ADDR. Since MN is using FA CoA in this to ALL-ZERO-ONE-ADDR. Since MN is using FA CoA in this example, it
example, it sends the Registration Request to the FA. The sends the Registration Request to the FA. The Registration Request
Registration Request looks as follows: looks as follows:
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| MN | FA | | ALL-ZERO-ONE-ADDR |FA CoA | | MN | FA | | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
If the MN is aware of an HA address, it can add that address in If the MN is aware of an HA address, it can add that address in the
the Requested HA extension in Registration Request. That Requested HA extension in Registration Request as a hint. That
extension is not shown above. extension is not shown above.
2. The FA sends the Registration Request to the Requested HA. 2. The FA sends the Registration Request to the Requested HA. The
The Registration Request looks as follows: Registration Request looks as follows:
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA |Requested HA| | ALL-ZERO-ONE-ADDR |FA CoA | | FA |Requested HA| | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
If MN had included the Requested HA extension, the Registration (If MN includes the Requested HA extension, the FA copies that
Request is sent to the HA address in that extension. extension. The FA then forwards the Registration Request, along
with the Requested HA extension, to the HA address specified in
Requested HA extension.)
3. HA processes the Registration Request in accordance with RFC 3. HA processes the Registration Request in accordance with Mobile
3344 and the messaging defined in this document. HA creates IPv4 [1] and the messaging defined in this document. HA creates
mobility binding for successful request. HA then sends mobility binding for successful request. HA then sends Registration
Registration Reply to the FA, which looks as follows. The Reply to the FA, which looks as follows. The Assigned HA address
Assigned HA address corresponds to the HA receiving and corresponds to the HA receiving and processing the request (and is
processing the request (and is same as Requested HA, only the same as Requested HA, only the name is changed for registration
name is changed for registration reply). reply).
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
|Assigned|CoA or NATed| | Assigned HA |FA CoA/| |Assigned| Src IP of | | Assigned HA |FA CoA/|
| HA | Src IP | | | | | HA | the RRQ | | | |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
4. The FA relays the Registration Reply to the MN, as follows. 4. The FA relays the Registration Reply to the MN, as follows.
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA | MN | | Assigned HA |FA CoA/| | FA | MN | | Assigned HA |FA CoA/|
+-----------------------------------------------------------+ +-----------------------------------------------------------+
5. The MN obtains Assigned HA address from the HA field in the 5. The MN obtains Assigned HA address from the HA field in the
successful Registration Reply and uses it for the remainder of successful Registration Reply and uses it for the remainder of the
the session. MN sends subsequent Re-Registration or De- session. MN sends subsequent Re-Registration or De-Registration
Registration Requests for the remaining session directly to the Requests for the remaining session directly to the Assigned HA.
Assigned HA. Note that the Assigned HA is the same as the Requested HA.
4.2 Messaging for HA redirection 4.2 Messaging for HA redirection
1. MN sets the Home Agent address field in the Registration This section describes the events that occur when the Requested HA
Request to ALL-ZERO-ONE-ADDR. does not accept the Registration Request and redirects the mobile
2. The MN (if using collocated CoA) or FA (if using FA CoA) node to another HA (aka Redirected HA) instead.
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 Registration Request.
3. When HA receives the Registration Request, if the HA field 1. MN sets the Home Agent address field in the Registration Request
is set to ALL-ZERO-ONE-ADDR, HA may reject the request to ALL-ZERO-ONE-ADDR.
with Reply code REDIRECT-HA-REQ and suggest an alternate
HA. 2. The MN (if using collocated CoA) or FA (if using FA CoA) 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 Registration Request.
3. When HA receives the Registration Request, if the HA field is
set to ALL-ZERO-ONE-ADDR, HA may reject the request with Reply
code REDIRECT-HA-REQ and suggest an alternate HA.
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 HAs address.
The IP address of the HA that is the target of the redirection
is specified in Redirected HA extension. The presence of this
extension is mandatory when the reply code is set to REDIRECT-
HA-REQ. HA sends the Reply to the FA/MN.
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 HAs address. The HA that is being referred to is
specified in Redirected HA extension. The presence of this
extension is mandatory when the reply code is set to
REDIRECT-HA-REQ. HA sends the Reply to the FA/MN
4. FA sends the Reply to the MN. 4. FA sends the Reply to the MN.
5. If the error code is set to REDIRECT-HA-REQ, MN obtains 5. If the error code is set to REDIRECT-HA-REQ, MN obtains the HA
the HA address from Redirected HA extension and sends a address from Redirected HA extension. The MN then sends a
Registration Request to this HA. Registration Request to Redirected HA, unless it has already
received a redirection response from this HA while processing
this Registration Request.
4.2.1 Example with Message Flow Diagram 4.2.1 Example with Message Flow Diagram
Figure 3 shows one specific example of a Mobile Node using FA Figure 3 shows one specific example of a Mobile Node using FA Care
Care of Address. of Address.
MN FA Requested HA Redirected HA MN FA Requested HA Redirected HA
| 1 | | | | 1 | | |
|------------>| 2 | | |------------>| 2 | |
| |--------------->| | | |--------------->| |
| | | | | | | |
| | | | | | | |
| | 3 | | | | 3 | |
| 4 |<---------------| | | 4 |<---------------| |
|<------------| | | |<------------| | |
| | | | | | | |
| | 5 | | | | 5 | |
|-------------------------------------------------> | |--------------------------------------------->|
| | | | | | | |
Figure 3: Example of Message flows for the specification Figure 3: Example of message flows for HA redirection
1. MN sets the Home Agent address field in the Registration 1. MN sets the Home Agent address field in the Registration Request
Request to ALL-ZERO-ONE-ADDR address. Since MN is using FA CoA to ALL-ZERO-ONE-ADDR address. Since MN is using FA CoA in this
in this example, it sends the Registration Request to the FA. example, it sends the Registration Request to the FA. The
The Registration Request looks as follows: Registration Request looks as follows:
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| MN | FA | | ALL-ZERO-ONE-ADDR |FA CoA | | MN | FA | | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
If the MN is aware of an HA address, it can add that address in If the MN is aware of an HA address, it can add that address in the
the Requested HA extension in Registration Request. That Requested HA extension in Registration Request as a hint. That
extension is not shown above. extension is not shown above.
2. The FA sends the Registration Request to the Requested HA. 2. The FA sends the Registration Request to the Requested HA. If
If Requested HA extension is present, Requested HA is the HA Requested HA extension is present, Requested HA is the HA address
address in this extension. The Registration Request looks as in this extension. The Registration Request looks as follows:
follows:
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA |Requested HA| | ALL-ZERO-ONE-ADDR |FA CoA | | FA |Requested HA| | ALL-ZERO-ONE-ADDR |FA CoA |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
3. HA processes the Registration Request in accordance with RFC 3. HA processes the Registration Request in accordance with Mobile
3344 and the messaging defined in this document. If the IPv4 [1] and the messaging defined in this document. If the
registration is successful, but local configuration/ registration is successful, but local configuration/ administrative
administrative policy etc. directs HA to refer the MN to policy etc. directs HA to refer the MN to another HA, HA rejects
another HA, HA rejects the Request with error code REDIRECT-HA- the Request with error code REDIRECT-HA-REQ. HA fills in the
REQ. HA fills in the address of the directed HA in the address of the Redirected HA in the Redirected HA extension. HA
Redirected HA extension. HA then sends Registration Reply then sends Registration Reply reject to the FA, which looks as
reject to the FA, which looks as follows: follows:
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| |CoA or NATed| | HA |FA CoA | | | Src IP of | | HA |FA CoA |
| HA | Src IP | | | | | HA | the RRQ | | | |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| Redirected HA extension ... | Redirected HA extension ... |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
4. The FA relays the Registration Reply to the MN, as follows. 4. The FA relays the Registration Reply to the MN, as follows.
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = |
| FA | MN | | HA |FA CoA/| | FA | MN | | HA |FA CoA/|
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| Redirected HA extension ... | Redirected HA extension ... |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
5. If MN can authenticate the Reply, MN extracts the HA address 5. If MN can authenticate the Reply, MN extracts the HA address
from Redirected HA extension and sends Registration Request to from Redirected HA extension. The MN then sends Registration
this HA. Request to Redirected HA, unless it has already received a
redirection response from this HA while processing the Registration
Request.
5. Mobility Agent Considerations for dynamic HA assignment 5. Mobility Agent Considerations
Following sections describe the behavior of each mobility agent Following sections describe the behavior of each mobility agent in
in detail. detail.
5.1 Mobile Node Considerations 5.1 Mobile Node Considerations
The mobile node MUST use NAI extension for home address The mobile node MUST use NAI extension for home address assignment
assignment when using the messaging mechanism in this document. when using the messaging mechanism in this document. Since MN uses
NAI extension, the Home Address field is set to 0.0.0.0.
While dynamic HA assignment is in progress and MN has not While dynamic HA assignment is in progress and MN has not
successfully anchored at a Home Agent, mobile node MUST set the successfully anchored at a Home Agent, mobile node MUST set the
Home Agent field in the Registration Request to an ALL-ZERO- Home Agent field in the Registration Request to an ALL-ZERO-ONE-
ONE-ADDR, which is either 255.255.255.255 or 0.0.0.0. ADDR, which is either 255.255.255.255 or 0.0.0.0.
The Registration Request MUST be protected by a valid The Registration Request MUST be protected by a valid authenticator
authenticator as specified in [1] or [5]. Configuring security as specified in Mobile IPv4 [1] or Mobile IPv4 Challenge/Response
associations is deployment specific and hence outside the scope Extensions [5]. Configuring security associations is deployment
of this specification. The security associations between a MN specific and hence outside the scope of this specification. The
and an individual HA may also be dynamically derived during the security associations between a MN and an individual HA may also be
dynamic HA assignment, based on a shared secret between MN and dynamically derived during the dynamic HA assignment, based on a
AAA infrastructure. shared secret between MN and AAA infrastructure [7].
The mobile node must maintain the remaining Mobile IP session The mobile node MUST maintain the remaining Mobile IP session with
with the Assigned HA. Following sections describe MN behavior the Assigned HA.
in FA CoA mode and collocated CoA mode.
Following sections describe MN behavior in FA CoA mode and
collocated CoA mode.
5.1.1 MN using FA CoA 5.1.1 MN using FA CoA
When a mobile node initiates Mobile IP session requesting When a mobile node initiates Mobile IP session requesting dynamic
dynamic HA assignment, it MUST set the home agent address field HA assignment, it MUST set the home agent address field in the
in the Registration Request to ALL-ZERO-ONE-ADDR. The Registration Request to ALL-ZERO-ONE-ADDR. The destination IP
destination IP address of Registration Request is the FA. The address of Registration Request is the FA. The FA will determine
FA will determine the Requested HA and forward the Registration the Requested HA and forward the Registration Request to the
Request to the Requested HA. Registration Request processing Requested HA. Registration Request processing takes place on the
takes place on the Requested HA as per the specification in Requested HA as per the specification in this draft.
this draft.
The Registration Request MUST be appropriately authenticated The Registration Request MUST be appropriately authenticated for
for the HA to validate the Request. the HA to validate the Request.
If successful Registration Reply is received, MN obtains If successful Registration Reply is received, MN obtains Assigned
Assigned HA from the HA field of Reply. HA from the HA field of Reply. Assigned HA address is the same as
Requested HA address.
If Registration Reply is received with code REDIRECT-HA-REQ, MN If Registration Reply is received with code REDIRECT-HA-REQ, MN
MUST authenticate the Reply based on HA address in HA field of MUST authenticate the Reply based on HA address in HA field of
Reply and attempt Registration with the HA address specified in Reply and attempt Registration with the HA address specified in the
the Redirected HA extension. In some cases, MN may want to hint Redirected HA extension. MN MUST put the Redirected HA in the HA
to the network to be anchored at a specific HA. In both these address of the Requested HA extension.
cases, MN MUST put the HA address in the Requested HA extension
in Registration Request. In some cases, for the first Registration Request MN may want to
hint to the network to be anchored at a specific HA and the MN MUST
put that address in the HA address of the Requested 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.
5.1.2 MN using Collocated CoA 5.1.2 MN using Collocated CoA
Mobile Node in collocated CoA mode requesting dynamic HA Mobile Node in collocated CoA mode requesting dynamic HA assignment
assignment MUST set the home agent address field in the MUST set the home agent address field in the Registration Request
Registration Request to ALL-ZERO-ONE-ADDR. The destination IP to ALL-ZERO-ONE-ADDR. The destination IP address of the
address of the Registration Request is the Requested HA. Some Registration Request is the Requested HA. Some ideas on how to
ideas to select a Requested HA are briefly covered in section select a Requested HA are briefly covered in section 6.
6.
If successful Reply is received, the MN obtains Assigned HA If successful Reply is received, the MN obtains Assigned HA address
address from successful Registration Reply. The MN MUST cache from successful Registration Reply. The Assigned HA will be same as
the Assigned HA address for the length of the Mobile IP Requested HA. The MN MUST cache the Assigned HA address for the
session. The mobile node then MUST use this previously cached length of the Mobile IP session. The mobile node then MUST use this
Assigned HA address as the home agent address in subsequent re- previously cached Assigned HA address as the home agent address in
registration and de-registration request(s). This will make subsequent re-registration and de-registration request(s). This
sure that the mobile node will always be anchored to the will make sure that for the duration of the Mobile IP session, the
assigned home agent with which it was initially registered. mobile node will always be anchored to the assigned home agent with
which it was initially registered.
If Registration Reply is received with code REDIRECT-HA-REQ, MN If Registration Reply is received with code REDIRECT-HA-REQ, MN
MUST authenticate the Reply based on HA address in HA field of MUST authenticate the Reply based on HA address in HA field of
Reply and attempt Registration with the HA address specified in Reply and attempt Registration with the HA address specified in the
the Redirected HA extension. In some cases, MN may want to hint Redirected HA extension. MN MUST put the Redirected HA in the HA
to the network to be anchored at a specific HA. In both these address of the Requested HA extension.
cases, MN MUST put the HA address in the Requested HA extension
in Registration Request. In some cases, for the first Registration Request MN may want to
hint to the network to be anchored at a specific HA and the MN MUST
put that address in the HA address of the Requested HA extension.
While requesting dynamic HA assignment in collocated CoA mode, While requesting dynamic HA assignment in collocated CoA mode,
Requested HA extension must always be included. Requested HA extension must always be included.
5.1.3 Refreshing Assigned HA Address on Mobile Node 5.1.3 Refreshing Assigned HA Address on Mobile Node
When the Mobile IP session terminates, the mobile node MAY When the Mobile IP session terminates, the mobile node MAY clear
clear the Assigned HA address cached as the home agent address. the Assigned HA address cached as the home agent address. It MAY
It MAY request a new HA address for the new Mobile IP session request a new HA address for the new Mobile IP session by not
by not including the Requested HA extension. The advantage of including the Requested HA extension. The advantage of this
this approach is that the mobile node will be always anchored approach is that the mobile node will be always anchored to an
to an optimal home agent from where it initiated Mobile IP optimal home agent from where it initiated Mobile IP session.
session.
Alternately, MN may save the Assigned HA address and use it in Alternately, MN may save the Assigned HA address and use it in the
the Requested HA extension along with ALL-ZERO-ONE HA address Requested HA extension along with ALL-ZERO-ONE-ADDR address in
in Registration Request. Registration Request.
5.2 Foreign Agent Considerations 5.2 Foreign Agent Considerations
When the mobile node is using foreign agent CoA, it sends the When the mobile node is using foreign agent CoA or MN using CCoA
Registration Request to the foreign agent. When the FA receives finds R bit is set in the FA advertisement, it sends the
a Registration Request with HA address field set to ALL-ZERO- Registration Request to the foreign agent.
ONE-ADDR, it obtains the Requested HA address to forward the
Registration Request. Some ideas to select a Requested HA are
briefly covered in section 6.
If the FA cannot obtain the Requested HA to forward a When the FA receives a Registration Request with HA address field
Registration Request from MN, it MUST reject request with error set to ALL-ZERO-ONE-ADDR and it doesn't contain the Requested HA
code NONZERO-HA-REQD. extension, FA obtains the Requested HA address to forward the
Registration Request. Some ideas on how to select a Requested HA
are briefly covered in section 6.
If the MN has included the Requested HA extension, FA MUST If the FA cannot obtain the Requested HA to forward a Registration
forward Registration Request to the address in this extension. Request from MN, it MUST reject request with error code NONZERO-HA-
If the HA address in this extension is not a routable unicast
address, FA MUST reject request with error code NONZERO-HA-
REQD. REQD.
Backward compatibility issues related to the mobility agents If the MN has included the Requested HA extension, FA MUST forward
are addressed in section 9. Registration Request to the address in this extension. If the HA
address in this extension is not a routable unicast address, FA
MUST reject 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.
Backward compatibility issues related to the mobility agents are
addressed in section 10.
5.3 Home Agent Considerations 5.3 Home Agent Considerations
Home Agent can process an incoming Registration Request in one
of the following three ways:
MN or FA sends the Registration Request to the Requested HA. Home Agent can process an incoming Registration Request in one of
The term Requested HA has meaning in context of the the following two ways:
Registration Request message. When the Requested HA
successfully processes Registration Request and creates a
binding and sends a Reply with its address, it becomes the
Assigned HA. The term Assigned HA is meaningful in context of a
Registration Reply message.
Home Agent receiving the request with HA field set to ALL-ZERO- 1. MN or FA sends the Registration Request to the Requested HA. The
ONE-ADDR MAY reject the request even if successfully term Requested HA has meaning in context of the Registration
authenticated for a multitude of reasons and suggest an Request message. When the Requested HA successfully processes
alternate HA address in Reply. In such a case, the HA puts its Registration Request and creates a binding and sends a Reply with
own address in HA field of Reply and sets the Reply code to its address, it becomes the Assigned HA. The term Assigned HA is
REDIRECT-HA-REQ and adds the Redirected HA extension. meaningful in context of a Registration Reply message.
If the Registration Request contains the Requested HA 2. Home Agent receiving the Registration Request with HA field set
extension, the HA address in that extension must match the to ALL-ZERO-ONE-ADDR MAY reject the request even if successfully
destination IP of the Request. authenticated and suggest an alternate HA address in Reply. In such
a case, the HA puts its own address in HA field of Reply and 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.
5.3.1 Assigned Home Agent Considerations 5.3.1 Assigned Home Agent Considerations
The HA that processes the incoming Registration Request fully The HA that processes the incoming Registration Request fully in
in accordance with RFC 3344 and this specification becomes the accordance with Mobile IPv4 [1] and this specification becomes the
Assigned HA. The Registration Request terminates at the Assigned HA. The Registration Request terminates at the Assigned
Assigned HA. HA.
The Assigned HA creates mobility bindings and sends The Assigned HA creates one mobility binding per MN and sends
Registration Reply to the MN by copying its address in the home Registration Reply to the MN by copying its address in the home
agent field and as the source IP address of the Reply. agent field and as the source IP address of the Reply.
There are two IP addresses to consider, destination IP address There are two IP addresses to consider, destination IP address and
and Home Agent address field in the Registration Request. When Home Agent address field in the Registration Request. When
destination IP address is unicast, only one HA receives the destination IP address is unicast, only one HA receives the
Registration Request. This HA should unambiguously accept or Registration Request. This HA should unambiguously accept or deny
deny the registration, regardless of the value in the Home the registration, regardless of the value in the Home Agent field.
Agent field. When the Home Agent field is non-unicast, the HA When the Home Agent field is non-unicast, the HA should set the
should set the value to its own IP address in the Registration value to its own IP address in the Registration Reply.
Reply.
The following table summarizes the behavior of Assigned HA. The following table summarizes the behavior of Assigned HA.
No. Dest IP Addr HA field Processing at Assigned HA Dest IP Addr HA field Processing at Assigned HA
-- ------------ ------------ ------------------------------- ------------ ------------ ----------------------------------
1 Unicast non-unicast RFC 3344: HA denies the
registration with error code
136 and sets HA field to its
own IP address in the reply as
per section 3.8.3.2.
ALL-ZERO- New Behavior: Accept the RRQ as Unicast non-unicast Mobile IPv4 [1]: There is no change
ONE-ADDR per this specification. in handling for this case from
Authenticate the RRQ and create (Must be Mobile IPv4. It is mentioned here
mobility binding if the HA is equal to the for reference only.
acting as Assigned HA. Set HA HA receiving HA denies the registration
field to its own IP address in the RRQ) with error code 136 and sets
the Registration Reply. HA field to its own IP
address in the reply as per
section 3.8.3.2 in [1].
ALL-ZERO-
ONE-ADDR New Behavior: Accept the RRQ as per
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 OR
New Behavior: Dest IP New Behavior: If authentication is
corresponds to the HA receiving successful, reject RRQ with a new
RRQ, if authentication is error code (REDIRECT-HA-REQ). HA
successful, reject RRQ with a puts its address in HA address
new error code (REDIRECT-HA- field of Reject. HA suggests an
REQ). HA puts its address in HA alternate HA to use in the new
address field of Reject. HA Redirected HA extension.
suggests an alternate HA to use
in the new Redirected HA
extension
Table 1: Registration Request handling at Assigned HA Table 1: Registration Request handling at Assigned HA
This specification also proposes a subtle difference in As per the messaging proposed here, the mobile node (or the foreign
behavior for case #1 above from RFC 3344. As per the messaging agent) sends the Registration Request to the Requested HA address,
proposed here, the mobile node (or the foreign agent) sends the which is a unicast address. Because HA does not receive
Registration Request to the Requested HA address, which is a Registration Request that is sent to the subnet-directed broadcast
unicast address. Because HA does not receive Registration address, Mobile IPv4 [1] section 3.8.2.1 doesn't apply. Although
Request that is sent to the subnet-directed broadcast address, the Home Agent field in the Registration Request is not a unicast
RFC 3344 section 3.8.2.1 doesn't apply. Although the Home
Agent field in the Registration Request is not a unicast
address, the destination IP address is a unicast address. This address, the destination IP address is a unicast address. This
avoids the problem associated with subnet-directed broadcast avoids the problem associated with subnet-directed broadcast
destination IP address that may result in multiple HAs destination IP address that may result in multiple HAs responding.
responding. Thus, there is no need to deny the registration as Thus, there is no need to deny the registration as stated in Mobile
stated in RFC 3344 section 3.8.3.2. IPv4 [1] section 3.8.3.2.
When the destination IP address is a unicast address and Home When the destination IP address is a unicast address and Home Agent
Agent field is ALL-ZERO-ONE-ADDR, the HA accepts/denies field is ALL-ZERO-ONE-ADDR, the HA accepts/denies registration and
registration and sets HA field to its own IP address in the sets HA field to its own IP address in the reply (i.e. registration
reply (i.e. registration is not rejected with error code 136). is not rejected with error code 136).
HA can reject the request with the error code REDIRECT-HA-REQ
and suggest an alternate HA. This redirection can be used for HA can reject the request with the error code REDIRECT-HA-REQ and
load-balancing, geographical proximity based on care-of-address suggest an alternate HA. This redirection can be used for load
or a multitude of reasons. HA puts its own address in HA field balancing, geographical proximity based on care-of-address or other
on Registration Reply message and put the address of the reasons. HA puts its own address in HA field of the Registration
redirected HA in the Redirected HA extension. If HA accepts the Reply message and puts the address of the redirected HA in the
Request, HA field in Reply is set to this HA address. Redirected HA extension. If HA accepts the Request, HA field in the
Registration Reply is set to this HA address.
The Assigned HA performs standard validity checks on the The Assigned HA performs standard validity checks on the
Registration Request. If there is any error, the Registration Registration Request. If there is any error, the Registration
Request is rejected with error codes specified in RFC 3344. Request is rejected with error codes specified in Mobile IPv4 [1].
6. Requested Home Agent Selection 6. Requested Home Agent Selection
The destination IP address of the Registration Request when When dynamic HA assignment is requested, the destination IP address
dynamic HA assignment is requested, is the Requested HA. This of the Registration Request is the Requested HA. This address MUST
address MUST be a unicast IP address. If the MN has included a be a unicast IP address. If the MN has included a Requested HA
Requested HA extension in Registration Request, the HA address extension in Registration Request, the HA address in this extension
in this extension is the Requested HA. is the Requested HA.
Some ideas on how to select the Requested HA are briefly Some example methods by which the MN or the FA may select the
covered in this section, however this draft neither suggests Requested HA are briefly described below:
nor mandates any specific mechanism. There can be more methods
for selecting the HA to the MN. Here is a high level overview
of some possibilities:
DHCP: DHCP:
MN performs DHCP to obtain an IP address on the visited MN performs DHCP to obtain an IP address on the visited network.
network. The Requested HA is learned from the DHCP Mobile IP The Requested HA is learned from the DHCP Mobile IP Home Agent
Home Agent Option 68 [4]. MN sends Registration Request Option 68 [4]. MN sends Registration Request directly to this HA
directly to this HA and receives the Assigned HA to be used for and receives the Assigned HA to be used for the remainder of the
the remainder of the Mobile IP session. Mobile IP session.
AAA: AAA:
MN performs challenge/response [5] with the FA. The FA MN performs challenge/response [5] with the FA. The FA retrieves
retrieves the Requested HA from the AAA server and forwards the the Requested HA from the AAA server and forwards the Registration
Registration Request directly to this HA. The Assigned HA Request directly to this HA. The Assigned HA sends Registration
sends Registration Reply to the FA, which relays it to the MN. Reply to the FA, which relays it to the MN. MN uses the Assigned
MN uses the Assigned HA for the remainder of the Mobile IP HA for the remainder of the Mobile IP session.
session.
DNS: DNS:
In this case hostname of HA is configured on MN or obtained by In this case hostname of HA is configured on MN or obtained by some
some other means e.g. using a service location protocol. MN other means e.g. using a service location protocol. MN performs DNS
performs DNS lookup on the HA hostname. The DNS infrastructure lookup on the HA hostname. The DNS infrastructure provides resource
provides resource record with information to identify the record with information to identify the nearest HA to the MN. The
nearest HA to the MN. The MN sends Registration Request MN sends Registration Request directly to the HA and receives the
directly to the HA and receives the Assigned HA to be used for Assigned HA to be used for remainder of the Mobile IP session.
remainder of the Mobile IP session.
Static configuration: Static configuration:
HA address is statically configured on MN. The MN uses the HA address is statically configured on MN. The MN sends the
configured address to send the Registration Request. Registration Request to the configured address.
7. Error Values 7. Error Values
Each entry in the following table contains the name and value Each entry in the following table contains the name and value for
for the error code to be returned in a Registration Reply. It the error code to be returned in a Registration Reply. It also
also includes the section in which the error code is first includes the section in which the error code is first mentioned in
mentioned in this document. this document.
Error Name Value Section Description Error Name Value Section Description
---------- ----- ------- ----------------------------- ---------- ----- ------- -----------------------------
NONZERO-HA-REQD XX 5.2 Non-zero HA address required NONZERO-HA-REQD XX 5.2 Non-zero HA address required
in Registration Request. in Registration Request.
REDIRECT-HA-REQ YY 5.3.1 Reregister with redirected HA. REDIRECT-HA-REQ YY 5.3 Reregister with redirected HA.
8. IANA Considerations 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. value in the range 64-127).
The code value NONZERO-HA-REQD defined in Section 7, correspond The code value REDIRECT-HA-REQ is a Mobile IP response code [1]
to error values conventionally associated with the rejection by taken from the range of values associated with rejection by the
the foreign agent (i.e. value in the range 64-127). The code home agent (i.e. value in the range 128-192).
value REDIRECT-HA-REQ defined in Section 7, correspond to error
values conventionally associated with the rejection by the home
agent (i.e. value in the range 128-192).
The Dynamic HA extension defined in section 3.4 corresponds to The Dynamic HA extension is assigned from the range of values
a skippable extension. associated with skippable extensions at the home agent (i.e. value
in the range 128-255).
IANA should record the values as defined in Section 7 and 3.4. IANA should record the values as defined in Section 7 and 3.4.
9. Security Considerations 9. Security Considerations
This specification assumes that the Mobile Node and Assigned This specification assumes that a security configuration has been
Home Agent are in the same administrative domain. This preconfigured between the MN and the HA or is configured along with
specification does not change or degrade the security model the initial RRQ/RRP as per [7].
established in RFC-3344. Most of the time Mobile Nodes will be This specification does not change or degrade the security model
connected to the network via wireless link. Such links are established in Mobile IPv4 [1]. Mobile Nodes are often connected to
vulnerable to passive eavesdropping, replay attacks or many the network via wireless link, which may be more prone to passive
other types of attacks. They are considered below. eavesdropping, replay attacks. Such an attack might lead to bogus
registrations or redirection of traffic or denial of service.
9.1 Message Authentication Codes As per the messaging in this draft, the Assigned Home Agent will
process the incoming Registration Request as per Mobile IPv4 [1].
Hence the Assigned Home Agent will have same security concerns as
that 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 The Registration Request and Registration Reply messages are
protected by a valid authenticator as specified in RFC 3344. protected by a valid authenticator as specified in Mobile IPv4 [1].
Configuring security associations is a deployment specific Configuring security associations is a deployment specific issue
issue and is covered by other specifications in Mobile IP WG. and is covered by other specifications in Mobile IP WG. There can
be many ways of configuring security associations, but this
There can be many ways of configuring security associations, specification does not mandate any specific way.
but this specification does not mandate any specific way.
An example is where the security association between a MN and An example is where the security association between a MN and an
an individual HA (Dynamic or Assigned) is dynamically derived individual HA (Dynamic or Assigned) is dynamically derived during
during the dynamic HA assignment, based on a shared secret the dynamic HA assignment, based on a shared secret between MN and
between MN and AAA infrastructure, as defined in [7]. The AAA infrastructure, as defined in [7]. The Registration Request is
Registration Request is protected with MN-AAA authentication protected with MN-AAA authentication extension and Registration
extension and Registration Reply is protected with MHAE. Since Reply is protected with MN-HA Authentication Extension. Since the
the security association is shared between MN and AAA, any security association is shared between MN and AAA, any dynamically
dynamically assigned HA in the local domain can proxy assigned HA in the local domain can proxy authenticate the MN using
authenticate the MN using AAA as per [7]. AAA as per [7].
The Assigned Home Agent authenticates Registration Request from The Assigned Home Agent authenticates Registration Request from the
the mobile node as specified in RFC-3344 and RFC-3012. The MN mobile node as specified in Mobile IPv4 [1] and RFC-3012. The MN
also authenticates the Registration Reply from the Assigned HA, also authenticates the Registration Reply from the Assigned HA,
thus the existing trust model in RFC 3344 is maintained. thus the existing trust model in Mobile IPv4 [1] is maintained.
9.2 Areas of Security Concern in this Protocol
As per the messaging in this draft, the Assigned Home Agent
will process the incoming Registration Request as per RFC-3344.
Hence the Assigned Home Agent will have same security concerns
as that of the Home Agent in RFC-3344. They are addressed in
Section 5 “Security Considerations” of RFC-3344.
10. Backward Compatibility Considerations 10. Backward Compatibility Considerations
In this section, we examine concerns that may arise when using this
specification in a mixed environment where some nodes implement the
specification and others do not. In each of the examples below, we
consider the case where one node is a "Legacy" node which does not
implement the specification in the context of other nodes which do.
Legacy Home Agent: Legacy Home Agent:
Legacy home agents may reject the Registration Request with Legacy home agents may reject the Registration Request with error
error code 136 because the Home Agent field is not a unicast code 136 because the Home Agent field is not a unicast address.
address. However, some legacy HA implementations may However, some legacy HA implementations may coincidentally process
coincidentally process the Registration Request in accordance the Registration Request in accordance with this draft, when the HA
with this draft, when the HA field in RRQ is set to ALL-ZERO- field in RRQ is set to ALL-ZERO-ONE-ADDR.
ONE-ADDR.
Legacy Foreign Agent: Legacy Foreign Agent:
Legacy foreign agents may forward Registration Request with Legacy foreign agents may forward Registration Request with home
home agent field set to ALL-ZERO-ONE-ADDR by setting the agent field set to ALL-ZERO-ONE-ADDR by setting the destination IP
destination IP address to ALL-ZERO-ONE-ADDR. This will result address to ALL-ZERO-ONE-ADDR. This will result packet being
packet being dropped or incidentally handled by a next hop HA, dropped or incidentally handled by a next hop HA, adjacent to the
adjacent to the FA. FA.
Legacy Mobile Node: Legacy Mobile Node:
MN that does not set HA field to ALL-ZERO-ONE-ADDR will MN that does not set HA field to ALL-ZERO-ONE-ADDR will continue to
continue to achieve its registrations through statically achieve its registrations through statically configured HA. In
configured HA. In collocated mode, the endpoint of the MN's collocated mode, the endpoint of the MN's tunnel is the Assigned
tunnel is the Assigned HA. HA.
11. Change Log from previous version 11. Change Log from previous versions
Changes from revision 1 to 2:
1. Editorial changes suggested by the WG, the chair's reviews
and idnits.
Changes from revision 0 to 1:
1. Added subtype field in Redirected HA Address Extension. 1. Added subtype field in Redirected HA Address Extension.
2. Aligned the HA address at 4-byte world boundary. 2. Aligned the HA address at 4-byte world boundary.
3. The case of handling unicast HA field is removed in section 3. The case of handling unicast HA field is removed in section
5.3.1. 5.3.1.
12. Intellectual Property Rights 12. Acknowledgements
The IETF takes no position regarding the validity or scope of
any intellectual property 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; neither does
it represent that it has made any effort to identify any such
rights. Information on the IETF's procedures with respect to
rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made
available for publication 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 Secretariat.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights, which may cover technology that may be
required to practice this standard. Please address the
information to the IETF Executive Director.
13. 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 draft. Also thanks to Henrik Levkowetz for
detailed reviews and suggestions.
The authors would like to thank Pete McCann for suggestions on The authors would like to thank Mike Andrews, Madhavi Chandra and
security considerations and definition of ALL-ZERO-ONE-ADDR. Yoshi Tsuda for their review and suggestions.
Thanks to Kuntal Chowdhury for extensive review and comments on
this draft. Also thanks to Henrik Levkowetz for detailed
reviews and suggestions.
The authors would like to thank Mike Andrews, Madhavi Chandra 13. Normative References
and Yoshi Tsuda for their review and suggestions.
14. References
[1] C. Perkins, "IP Mobility Support for IPv4", RFC 3344, August [1] C. Perkins, "IP Mobility Support for IPv4", RFC 3344, August
2002. 2002.
[2] P. Calhoun and C. Perkins, "Mobile IP Network Access Identifier [2] P. Calhoun and C. Perkins, "Mobile IP Network Access Identifier
Extension for IPv4", RFC 2794, March 2000. Extension for IPv4", RFC 2794, March 2000.
[3] D. Senie, "Changing the Default for Directed Broadcasts in [3] D. Senie, "Changing the Default for Directed Broadcasts in
Routers", RFC 2644, August 1999. Routers", RFC 2644, August 1999.
[4] S. Alexander and R. Droms, "DHCP Options and BOOTP Vendor [4] S. Alexander and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[5] C. Perkins and P. Calhoun, "Mobile IPv4 Challenge/Response [5] C. Perkins and P. Calhoun, "Mobile IPv4 Challenge/Response
Extensions", RFC 3012, November 2000. Extensions", RFC 3012, November 2000.
[6] H. Levkowetz and S. Vaarala, "Mobile IP Traversal of Network [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Address Translation (NAT) Devices", RFC 3519, April 2003. Levels", BCP 14, RFC 2119, March 1997.
[7] C. Perkins and P. Calhoun, "AAA Registration Keys for Mobile [7] C. Perkins and P. Calhoun, "AAA Registration Keys for Mobile
IP", draft-ietf-mobileip-aaa-key-13.txt, 22 June 2003. IP", draft-ietf-mip4-aaa-key-06.txt, June 2004.
[8] Jari Arkko, et. al., “Thoughts on bootstrapping mobility
securely” as presented at 57th IETF in Vienna, Austria, 16th
July, 2003
Authors' Addresses Authors' Addresses
Milind Kulkarni Milind Kulkarni
Cisco Systems Inc. Cisco Systems Inc.
170 W. Tasman Drive, 170 W. Tasman Drive,
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: mkulkarn@cisco.com Email: mkulkarn@cisco.com
skipping to change at page 20, line 51 skipping to change at page 21, line 15
Kent Leung Kent Leung
Cisco Systems Inc. Cisco Systems Inc.
170 W. Tasman Drive, 170 W. Tasman Drive,
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: kleung@cisco.com Email: kleung@cisco.com
Phone: +1 408-526-5030 Phone: +1 408-526-5030
Full Copyright Statement Intellectual Property Statement
Copyright (C) The Internet Society (2004). 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 The IETF takes no position regarding the validity or scope of any
any Intellectual Property Rights or other rights that might be Intellectual Property Rights or other rights that might be claimed
claimed to pertain to the implementation or use of the to pertain to the implementation or use of the technology described
technology described in this document or the extent to which in this document or the extent to which any license under such
any license under such rights might or might not be available; rights might or might not be available; nor does it represent that
nor does it represent that it has made any independent effort it has made any independent effort to identify any such rights.
to identify any such rights. Information on the procedures Information on the procedures with respect to rights in RFC
with respect to rights in RFC documents can be found in BCP 78 documents can be found in BCP 78 and BCP 79.
and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of assurances of licenses to be made available, or the result of an
an attempt made to obtain a general license or permission attempt made to obtain a general license or permission for the use
for the use of such proprietary rights by implementers or of such proprietary rights by implementers or users of this
users of this specification can be obtained from the IETF specification can be obtained from the IETF on-line IPR repository
on-line IPR repository at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be proprietary rights that may cover technology that may be required
required to implement this standard. Please address the to implement this standard. Please address the information to the
information to the IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2003). 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.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by Funding for the RFC Editor function is currently provided by the
the Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/