draft-ietf-mip4-dynamic-assignment-06.txt   draft-ietf-mip4-dynamic-assignment-07.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 : 12 October 2005 Cisco Systems Inc. Date : 12 December 2005 Cisco Systems Inc.
Mobile IPv4 Dynamic Home Agent Assignment Mobile IPv4 Dynamic Home Agent Assignment
draft-ietf-mip4-dynamic-assignment-06.txt draft-ietf-mip4-dynamic-assignment-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in 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 April 12, 2006. This Internet-Draft will expire on June 12, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
Mobile IPv4 [1] uses the Home Agent (HA) to anchor sessions of a Mobile IPv4 [1] uses the Home Agent (HA) to anchor sessions of a
roaming Mobile Node (MN). This draft proposes a messaging mechanism roaming Mobile Node (MN). This draft proposes a messaging mechanism
for dynamic home agent assignment and HA redirection. The goal is to for dynamic home agent assignment and HA redirection. The goal is to
skipping to change at page 2, line 37 skipping to change at page 2, line 37
5.3 Home Agent Considerations..................................15 5.3 Home Agent Considerations..................................15
5.3.1 Assigned Home Agent Considerations.......................16 5.3.1 Assigned Home Agent Considerations.......................16
6. Requested Home Agent Selection.............................17 6. Requested Home Agent Selection.............................17
7. Error Values...............................................18 7. Error Values...............................................18
8. IANA Considerations........................................18 8. IANA Considerations........................................18
9. Security Considerations....................................19 9. Security Considerations....................................19
10. Backward Compatibility Considerations.....................20 10. Backward Compatibility Considerations.....................20
11. Change Log from previous versions.........................21 11. Change Log from previous versions.........................21
12. Acknowledgements..........................................22 12. Acknowledgements..........................................22
13. Normative References......................................22 13. Normative References......................................22
Authors' Addresses.............................................22 Authors' Addresses.............................................23
Intellectual Property Statement................................23 Intellectual Property Statement................................23
1. Introduction 1. Introduction
This document adds to the Mobile IP protocol [1], by proposing a This document adds to the Mobile IP protocol [1], by proposing a
messaging mechanism for dynamic home agent assignment and home agent messaging mechanism for dynamic home agent assignment and home agent
redirection during initial registration. The goal is to assign an redirection during initial registration. The goal is to assign an
optimal HA for a Mobile IP session. The mobile node MUST use the optimal HA for a Mobile IP session. The mobile node MUST use the
Network Access Identifier (NAI) extension [2] when requesting a Network Access Identifier (NAI) extension [2] when requesting a
dynamically assigned HA. dynamically assigned HA.
skipping to change at page 10, line 52 skipping to change at page 10, line 52
Request, the HA field in the Reply is set to this HAs address. 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 The IP address of the HA that is the target of the redirection is
specified in Redirected HA Extension. The presence of this specified in Redirected HA Extension. The presence of this
extension is mandatory when the reply code is set to REDIRECT-HA- extension is mandatory when the reply code is set to REDIRECT-HA-
REQ. HA sends the Reply to the FA/MN. 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 the HA 5. If the error code is set to REDIRECT-HA-REQ, MN obtains the HA
address from Redirected HA Extension. The MN then sends a address from Redirected HA Extension. The MN then sends a
Registration Request to Redirected HA, unless it has already Registration Request to Redirected HA. The MN may choose to add
received a redirection response from this HA while processing this Requested HA extension in this new Registration Request. If a
Registration Request. The MN may choose to add Requested HA registration loop occurs (the case when the Redirected HA is an HA
extension in this new Registration Request. that had already directed the MN to register elsewhere) then the
MN stops sending any further Registration Request and provides an
indication that the loop event was detected. The number of
consecutive Redirected HAs remembered by MN for loop detection is
an implementation parameter.
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-located Figure 3 shows one specific example of a Mobile Node using FA-located
Care of Address, where the FA is not a legacy FA. Care of Address, where the FA is not a legacy FA.
MN FA Requested HA Redirected HA MN FA Requested HA Redirected HA
| 1 | | | | 1 | | |
|------------>| 2 | | |------------>| 2 | |
| |--------------->| | | |--------------->| |
skipping to change at page 13, line 22 skipping to change at page 13, line 22
Extensions [5]. Configuring security associations is deployment Extensions [5]. Configuring security associations is deployment
specific and hence outside the scope of this specification. The specific and hence outside the scope of this specification. The
security associations between a MN and an individual HA may also be security associations between a MN and an individual HA may also be
dynamically derived during the dynamic HA assignment, based on a dynamically derived during the dynamic HA assignment, based on a
shared secret between MN and AAA infrastructure [7]. shared secret between MN and AAA infrastructure [7].
The mobile node MUST maintain the remaining Mobile IP session with The mobile node MUST maintain the remaining Mobile IP session with
the Assigned HA. the Assigned HA.
As mentioned in the Security Considerations (Section 9), there is a As mentioned in the Security Considerations (Section 9), there is a
possibility of more than one HA create a mobility binding entry for possibility of more than one HA create a mobility binding entry for a
a given MN, if a rogue node in the middle captures the Registration given MN, if a rogue node in the middle captures the Registration
Request and forwards it to other Home Agents. MN can mitigate such Request and forwards it to other Home Agents. MN can mitigate such
condition by using a short lifetime (e.g. 5 seconds) in the condition by using a short lifetime (e.g. 5 seconds) in the
Registration Request with Home Agent field set to ALL-ZERO-ONE-ADDR. Registration Request with Home Agent field set to ALL-ZERO-ONE-ADDR.
The following sections describe MN behavior in FA CoA mode and co- The following sections describe MN behavior in FA CoA mode and co-
located CoA mode. located CoA mode.
5.1.1 MN using FA CoA 5.1.1 MN using FA CoA
When a mobile node initiates a Mobile IP session requesting dynamic When a mobile node initiates a Mobile IP session requesting dynamic
skipping to change at page 19, line 24 skipping to change at page 19, line 24
the range 128-255). 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 a security configuration has been This specification assumes that a security configuration has been
preconfigured between the MN and the HA or is configured along with preconfigured between the MN and the HA or is configured along with
the initial Registration Request/Registration Reply as per [7]. the initial Registration Request/Registration Reply as per [7].
There is a possibility of more than one HA create a mobility There is a possibility of more than one HA create a mobility binding
binding entry for a given MN, if a man in the middle captures the entry for a given MN, if a man in the middle captures the
Registration Request with HA field set to ALL-ZERO-ONE-ADDR and Registration Request with HA field set to ALL-ZERO-ONE-ADDR and
forwards it to other HAs. This scenario assumes that the rogue node forwards it to other HAs. This scenario assumes that the rogue node
can find out the addresses of the HAs which are able to authenticate can find out the addresses of the HAs which are able to authenticate
the Registration Request. It also assumes that the rogue node has the Registration Request. It also assumes that the rogue node has
the capability to store, duplicate, and send packets to the other HAs the capability to store, duplicate, and send packets to the other HAs
within the limited time of the replay window. Otherwise these HAs within the limited time of the replay window. Otherwise these HAs
will reject the Registration Requests anyway. In addition, this type will reject the Registration Requests anyway. In addition, this type
of attack is only possible when the Requested HA Extension is not of attack is only possible when the Requested HA Extension is not
included in the registration message. The Mobile Node can minimize included in the registration message. The Mobile Node can minimize
the duration of this condition by using a short lifetime (e.g. 5 the duration of this condition by using a short lifetime (e.g. 5
skipping to change at page 21, line 28 skipping to change at page 21, line 28
A MN that sends a registration request to an FA which can do dynamic A MN that sends a registration request to an FA which can do dynamic
HA assignment, but does not set the HA field to ALL-ZERO-ONE-ADDR HA assignment, but does not set the HA field to ALL-ZERO-ONE-ADDR
will continue to be registered with its statically configured HA, will continue to be registered with its statically configured HA,
exactly according to RFC 3344. exactly according to RFC 3344.
11. Change Log from previous versions 11. Change Log from previous versions
Note: This section should be removed before publication. Note: This section should be removed before publication.
Changes from revision 6 to 7:
1. Updated section 4.2 bullet 5.
Changes from revision 5 to 6: Changes from revision 5 to 6:
1. Updated section 4.2.1 bullet 5. 2. Updated section 4.2.1 bullet 5.
2. Fixed nits found by idnit tool. 3. Fixed nits found by idnit tool.
3. Added text in section 5.1 outlining how to avoid the 4. Added text in section 5.1 outlining how to avoid the
possibility of multiple bindings on HAs by requiring short possibility of multiple bindings on HAs by requiring short
lifetime for first registration request. lifetime for first registration request.
4. Added text in section 9 outlining possibility of multiple 5. Added text in section 9 outlining possibility of multiple
bindings on HAs. bindings on HAs.
5. Added text in section 12 Acknowledgements. 6. Added text in section 12 Acknowledgements.
Changes from revision 4 to 5: Changes from revision 4 to 5:
1. Legacy FA Considerations text was updated based on the WG 1. Legacy FA Considerations text was updated based on the WG
discussions which addressed IESG review feedback. discussions which addressed IESG review feedback.
Changes from revision 3 to 4: Changes from revision 3 to 4:
1. Text added to clarify the cases when MN is configured with HA 1. Text added to clarify the cases when MN is configured with HA
address and not configured with HA address and requests address and not configured with HA address and requests
 End of changes. 11 change blocks. 
17 lines changed or deleted 25 lines changed or added

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