Mobile IP Working Group Milind Kulkarni INTERNET-DRAFT Alpesh Patel Category: Informational Kent Leung Date : 20 January 2003 Cisco Systems Inc. Mobile IPv4 Dynamic Home Agent Assignment Framework Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Mobile IP (RFC 3344) uses the Home Agent (HA) to anchor sessions of a roaming Mobile Node (MN). The distance between a MN and HA affects the latency for control and data traffic. When the distance between the MN and HA is large, the resulting latency may be unacceptable. Therefore, it is advantageous to select a nearest HA to the MN during initial registration. There are other reasons for assigning an optimal HA beyond just locality, such as administrative policies, load balancing etc. This draft proposes a generic lightweight dynamic home agent assignment framework. The goal of the framework is to provide a mechanism to assign an optimal HA for a Mobile IP session while allowing any suitable method for HA assignment. The mobile node uses NAI extension for home address assignment. Kulkarni, Patel, Leung Expires July 20, 2003 [Page 1] Internet Draft Dynamic HA Assignment 20 January 2003 Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. Problem Statement..............................................4 3.1 General Assumptions...........................................4 3.2 Dynamic Home Agent Discovery in RFC 3344......................5 4. Dynamic Home Agent Assignment Framework........................5 4.1 Example with Message Flow Diagram.............................7 5. Mobility Agent Considerations..................................8 5.1 Mobile Node Considerations....................................8 5.1.1 MN using FA CoA.............................................9 5.1.2 MN using Collocated CoA.....................................9 5.1.3 Refreshing Assigned HA Address on Mobile Node..............10 5.2 Foreign Agent Considerations.................................10 5.3 Home Agent Considerations....................................10 5.3.1 Directed Home Agent Considerations.........................10 5.3.2 Assigned Home Agent Considerations.........................11 5.4 Directed Home Agent Selection................................13 5.5 Assigned Home Agent Selection................................14 6. Error Values..................................................14 7. IANA Considerations...........................................14 8. Security Considerations.......................................15 9. Backward Compatibility Considerations.........................15 10. Intellectual Property Rights.................................15 11. Acknowledgements.............................................16 12. References...................................................16 Authors' Addresses...............................................16 Full Copyright Statement.........................................17 1. Introduction This document adds to the Mobile IP protocol [1], by proposing a lightweight dynamic home agent assignment framework. The goal of the framework is to assign an optimal HA for a Mobile IP session. The mobile node uses Network Access Identifier (NAI) extension for home address assignment. Mobile IPv4 NAI Extension for IPv4 [2] introduced the concept of identifying a MN by the NAI and enabling dynamic home address assignment. In this case, it would be preferable to have a method to allocate the home agent address dynamically as well. It is important to note that this draft proposes a generic framework only, which can be used as a common foundation to facilitate dynamic HA assignment using any suitable method. The details on how to select the optimal HA are outside the scope of this draft. The framework neither mandates use of a specific method for selecting the optimal HA, nor does it preclude the use of other methods. There can be many methods for selecting the optimal HA, depending upon deployment, mobility Kulkarni, Patel, Leung Expires July 20, 2003 [Page 2] Internet Draft Dynamic HA Assignment 20 January 2003 architectures and topology. Hence the methods are best addressed in separate drafts. As per the framework in this draft, MN sets the Home Agent address to ALL-ZERO-ONE-ADDR (defined below) and sends the Registration Request to a "Directed HA". The MN obtains an "Assigned HA" address from successful Registration Reply and uses it for the rest of the session. Detailed definition of terms and operation is described shortly. 2. Terminology ALL-ZERO-ONE-ADDR: IP address 0.0.0.0 or 255.255.255.255. Directed HA: Destination IP address of Home Agent that the first Registration Request is sent to. Must be a unicast destination IP address. Assigned HA: Home Agent address field obtained from successful Registration Reply. It is the optimal Home Agent for the given mobile IP session. This address is used for the remainder of the Mobile IP session. AAA server: Authentication, Authorization and Accounting Server. DNS: Domain Name Service. DHCP: Dynamic Host Configuration Protocol. MN: Mobile Node as defined in RFC 3344. HA: Home Agent as defined in RFC 3344. FA: Foreign Agent as defined in RFC 3344. CoA: Care of Address. CCoA: Collocated Care of Address. MN HoA: Mobile Node's Home Address. NAI: Network Access Identifier [2]. Src IP: Source IP address of the packet. Dest IP: Destination IP address of the packet. Kulkarni, Patel, Leung Expires July 20, 2003 [Page 3] Internet Draft Dynamic HA Assignment 20 January 2003 3. Problem Statement In Mobile IP, mobile node registers with its home agent when it moves. 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. However, when looking at typical service provider or enterprise deployments, we find that the networks are geographically dispersed in moderately sized coverage areas, within a single large administrative domain. In such networks, it is possible to place the home agents in each geographical area. When a Mobile IP session initiates, the mobile node, foreign agent, home agent, AAA or other entity may select the optimal home agent for that session. The mobile node is assigned the selected optimal home agent, and uses it for the duration of the session. This drastically reduces the latency between the home agent and mobile node. 3.1 General Assumptions An example is illustrated in Figure 1, showing multiple network sites servicing different regions, which may be geographically dispersed. Each site has one home agent for anchoring the mobile nodes and has many (or no) foreign agents. A mobile node will typically roam within a geographical area during a mobility session. When the user travels long distance, the mobile node is quite likely to be powered on and off. Some mobile nodes may roam into other areas, away from the network where they initially registered. However, since majority remain within or close to the original site, selecting a home agent nearest to the initial location provides the optimal signaling and data path for the duration of the session. Kulkarni, Patel, Leung Expires July 20, 2003 [Page 4] Internet Draft Dynamic HA Assignment 20 January 2003 +-----------------------+ +-----------------------+ | Network West | | Network East | | | | | | +-----+ | | +-----+ | | | HA | | | | HA | | | +--+--+ | | +--+--+ | | | | | | | | +----+-----+ | | +----+-----+ | | | | +------------+ | | | | +--+--+ +--+--+ | | +--+--+ +--+--+ | | | FA | .. | FA | | | | R | .. | R | | | +--+--+ +-----+ | | +--+--+ +-----+ | | | | | | | | +--+--+ | | +--+--+ | | | MN | | | | MN | | | +-----+ | | +-----+ | | | | R = Router | +-----------------------+ +-----------------------+ Figure 1: Geographically distributed networks with regional Mobile IP agents 3.2 Dynamic Home Agent Discovery in RFC 3344 Mobile IP RFC 3344 specifies the mechanism for discovering the mobile node's home agent using subnet-directed broadcast IP address in the home agent field of the Registration Request. This scheme was designed for mobile nodes with a static home address and subnet prefix, anchored on fixed home network. But using subnet-directed broadcast as the destination IP address of the Registration Request, it is unlikely that the Registration Request will reach the home subnet because routers will drop these packets by default. See CERT Advisory CA-1998- 01 Smurf IP Denial-of-Service Attacks [3]. 4. Dynamic Home Agent Assignment Framework This draft proposes following framework: 1. MN sets the Home Agent address field in the Registration Request to ALL-ZERO-ONE-ADDR. 2. The MN (if using collocated CoA) or FA (if using FA CoA) sends the Registration Request to the "Directed HA". 3. Typically the "Directed HA" is same as the "Assigned HA". However, this framework does not prevent the "Directed HA" and "Assigned HA" from being different. If they are Kulkarni, Patel, Leung Expires July 20, 2003 [Page 5] Internet Draft Dynamic HA Assignment 20 January 2003 different, the "Directed HA" forwards the Registration Request to the "Assigned HA". 4. "Assigned HA" is the final home agent, which processes the Registration Request in accordance with RFC 3344 and as per the framework in this document. It creates mobility binding for successful Registration Request. It also sends Registration Reply to the MN. 5. The MN obtains an "Assigned HA" address from the HA field in the successful Registration Reply and uses it for the remainder of the session. Packet formats in this framework are given below. Packet format for Registration Request sent by MN: +-----------------------------------------------------------+ | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | | MN | Directed HA| | ALL-ZERO-ONE-ADDR | CCoA/ | | | or FA | | |FA CoA | +-----------------------------------------------------------+ Packet format for Registration Reply received by MN: +-----------------------------------------------------------+ | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | | FA/HA | MN | | Assigned HA |FA CoA/| | | | | | CCoA | +-----------------------------------------------------------+ This draft proposes a generic framework only, which can be used to facilitate Dynamic HA assignment using any suitable method. More often than not, the Directed HA and the Assigned HA will be the same. However, this framework provides the flexibility of decoupling Directed HA and Assigned HA. Section 5.3.1 describes the Directed HA in detail. It is important to note that most of the time the Directed HA will be same as Assigned HA. In such a case the Directed HA will process the Registration Request as an Assigned HA. The details on how to select the Directed HA are outside the scope of this draft. However, some possible ideas are briefly covered in section 5.4. Section 5.3.2 describes the Assigned HA in detail. The details on how to select the Assigned HA are also outside the scope of this document. Kulkarni, Patel, Leung Expires July 20, 2003 [Page 6] Internet Draft Dynamic HA Assignment 20 January 2003 4.1 Example with Message Flow Diagram Detailed explanation of this framework is best described with the help of a railroad diagram and description. Figure 2 shows one specific example of a Mobile Node using FA Care of Address. The example assumes Directed HA and Assigned HA as separate entities. Other scenarios such as mobile node using collocated care of address and either combined or separate Directed/Assigned HA are not described below, but the behavior is similar. MN FA Directed HA Assigned HA | 1 | | | |------------>| 2 | | | |--------------->| 3 | | | |---------------->| | | | | | | 4 | | | 5 |<---------------------------------| |<------------| | | | | | | | | 6 | | |----------------------------------------------->| | | | | | | | | Figure 2: Example of Message flows for the framework 1. MN sets the Home Agent address field in the Registration Request to ALL-ZERO-ONE-ADDR. Since MN is using FA CoA in this example, it sends the Registration Request to the FA. The Registration Request looks as follows: +-----------------------------------------------------------+ | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | | MN | FA | | ALL-ZERO-ONE-ADDR |FA CoA | +-----------------------------------------------------------+ 2. The FA sends the Registration Request to the Directed HA. The Registration Request looks: +-----------------------------------------------------------+ | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | | FA |Directed HA | | ALL-ZERO-ONE-ADDR |FA CoA | +-----------------------------------------------------------+ 3. The Directed HA forwards the Registration Request to the Assigned HA. Kulkarni, Patel, Leung Expires July 20, 2003 [Page 7] Internet Draft Dynamic HA Assignment 20 January 2003 +-----------------------------------------------------------+ | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | |Directed|Assigned HA | | ALL-ZERO-ONE-ADDR |FA CoA | | HA | | | | | +-----------------------------------------------------------+ 4. Assigned HA processes the Registration Request in accordance with RFC 3344 and the framework defined in this document. Creates mobility binding for successful request. Assigned HA then sends Registration Reply to the FA, which looks as follows: +-----------------------------------------------------------+ | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | |Assigned| FA | | Assigned HA |FA CoA/| | HA | | | | | +-----------------------------------------------------------+ 5. The FA relays the Registration Reply to the MN, as follows. +-----------------------------------------------------------+ | Src IP=| Dest IP = | MN HoA | HA Address = | CoA = | | FA | MN | | Assigned HA |FA CoA/| +-----------------------------------------------------------+ 6. The MN obtains Assigned HA address from the HA field in the successful Registration Reply and uses it for the remainder of the session. MN sends subsequent Re-Registration or De- Registration Requests for the remaining session directly to the Assigned HA. 5. Mobility Agent Considerations Following sections describe the behavior of each mobility agent in detail. 5.1 Mobile Node Considerations The mobile node uses NAI extension for home address assignment. A mobile node MUST set the Home Agent field in the Registration Request to ALL-ZERO-ONE-ADDR. The Registration Request must be protected by a valid authenticator as specified in RFC 3344. Configuring security associations is deployment specific and hence outside the scope of this framework. There can be many ways of configuring security associations, but this framework does not mandate any specific way. Example of one such implementation is where MN shares identical security associations with all the Directed HA(s) and Assigned HA(s) in the network. The mobile node uses Kulkarni, Patel, Leung Expires July 20, 2003 [Page 8] Internet Draft Dynamic HA Assignment 20 January 2003 appropriate authentication extension to protect the Registration Request. The security associations between a MN and an individual HA (Dynamic or Assigned) may also be dynamically derived during the dynamic HA assignment. The mobile node must maintain the remaining Mobile IP session with the Assigned HA. Following sections describe MN behavior in FA CoA mode and collocated CoA mode. 5.1.1 MN using FA CoA When a mobile node initiates Mobile IP session, it MUST set the home agent address field in the Registration Request to ALL- ZERO-ONE-ADDR. The destination IP address of Registration Request is the FA. The FA will determine the Directed HA and forward the Registration Request to the Directed HA. The Directed HA in turn forwards the Registration Request to the Assigned HA. Normal Registration Request processing takes place on the Assigned HA. The MN obtains Assigned HA address from successful Registration Reply. The MN MUST cache the Assigned HA address for the length of the Mobile IP session. The mobile node then MUST use this previously cached Assigned HA address as the home agent address in subsequent re-registration and de-registration request(s). This will make sure that the mobile node will always be anchored to the assigned home agent with which it was initially registered. 5.1.2 MN using Collocated CoA When a mobile node using collocated CoA initiates Mobile IP session, it MUST set the home agent address field in the Registration Request to ALL-ZERO-ONE-ADDR. The destination IP address of the Registration Request is the Directed HA. The details of how to select Directed HA are outside the scope of this draft. However, some possible ideas are briefly covered in section 5.4. The MN obtains Assigned HA address from successful Registration Reply. The MN MUST cache the Assigned HA address for the length of the Mobile IP session. The mobile node then MUST use this previously cached Assigned HA address as the home agent address in subsequent re-registration and de-registration request(s). This will make sure that the mobile node will always be anchored to the assigned home agent with which it was initially registered. Kulkarni, Patel, Leung Expires July 20, 2003 [Page 9] Internet Draft Dynamic HA Assignment 20 January 2003 5.1.3 Refreshing Assigned HA Address on Mobile Node When the Mobile IP session terminates, the mobile node MAY clear the Assigned HA address cached as the home agent address. It MAY request a new Assigned HA address (using the framework described earlier) for the new Mobile IP session. The advantage of this approach is that the mobile node will be always anchored to its optimal home agent from the place where the mobile node initiated Mobile IP session. 5.2 Foreign Agent Considerations When the mobile node is using foreign agent CoA, it sends the Registration Request to the foreign agent. When the FA receives a Registration Request with HA address field set to ALL-ZERO- ONE-ADDR, it obtains the Directed HA address to forward the Registration Request. The details on how to select Directed HA are outside the scope of this draft. However, some possible ideas are briefly covered in section 5.4. If the FA cannot obtain the Directed HA to forward a Registration Request from MN, it MUST reject request with error code NONZERO-HA-REQD. Backward compatibility issues related to the mobility agents are addressed in section 9. 5.3 Home Agent Considerations Most of the time Directed HA and the Assigned HA will be the same. In such a case the Directed HA will not forward the Registration Request further, but will process it as an Assigned HA. However, this framework provides the flexibility of decoupling Directed HA and Assigned HA. 5.3.1 Directed Home Agent Considerations Directed HA is involved only in the first Registration Request processing and plays mostly passive role in the framework. The Directed HA simply forwards the Registration Request to a suitable home agent. This framework allows the presence of multiple Directed HAs in the network. At present, there is no foreseen need of multiple levels of Directed HAs, but this allows that possibility. If there are multiple Directed HAs, the first Registration Request simply gets forwarded to the next Directed HA until it reaches the Assigned HA. The Directed HA should not change the mobile Kulkarni, Patel, Leung Expires July 20, 2003 [Page 10] Internet Draft Dynamic HA Assignment 20 January 2003 IP header and associated extensions while forwarding the Registration Request. This draft does not mandate specific functionality, other than mentioned above, on the Directed HA and leaves open for implementation. The Directed HA may be used for providing geographic proximity. A simple Mobile IP aware server load balancer is one example of a Directed HA. The details on how to select the Directed HA are outside the scope of this draft. However, some possible ideas are briefly covered in section 5.4. The details on how to select the Assigned HA are also outside the scope of this document. 5.3.2 Assigned Home Agent Considerations The HA that processes the incoming Registration Request fully in accordance with RFC 3344 and this framework becomes the Assigned HA. In other words, the Registration Request finally terminates at the Assigned HA. The Assigned HA creates mobility bindings and sends Registration Reply to the MN by copying its address in the home agent field. As an example, the network can deploy several Assigned HAs (from which an optimal Assigned HA is selected by the Directed HA) for optimizing the load of mobility processing. There are two IP addresses to consider, destination IP address and Home Agent address field in the Registration Request. When destination IP address is unicast, only one HA receives the Registration Request. This HA should unambiguously accept or deny the registration, regardless of the value in the Home Agent field. When the Home Agent field is non-unicast, the HA should set the value to its own IP address in the Registration Reply. The following table summarizes the behavior of Assigned HA. Kulkarni, Patel, Leung Expires July 20, 2003 [Page 11] Internet Draft Dynamic HA Assignment 20 January 2003 No. Dest IP Addr HA field Processing at Assigned HA 1 Unicast unicast Normal HA processing per RFC 3344. 2 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. ALL-ZERO- NEW BEHAVIOR: Accept the RRQ as ONE-ADDR per this framework. 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. 3 Non-unicast unicast RFC 3344: HA rejects with error code 136 and sets HA field to its own IP address in the reply. 4 Non-unicast Non-unicast RFC 3344: HA rejects with error code 136 and sets HA field to its own IP address in the reply. Table 1: Registration Request handling at Assigned HA Following sections describe the Registration Request handling by the home agent as per the existing provisions of RFC 3344. 1) RFC 3344 section 3.8.2.1 states that home agents MUST deny Registration Requests that are sent to the subnet-directed broadcast address of the home network. The home agent MUST discard the Request and SHOULD return a Registration Reply with a Code of 136. The Registration Reply will contain the home agent's unicast address, so that the mobile node can re-issue the Registration Request with the correct home agent address. This refers to cases #3 and #4 in the table above. 2) RFC 3344 section 3.8.3.2 states that if the Home Agent field in the Registration Request contains a unicast address of this home agent, then that field MUST be copied into the Home Agent field of the Registration Reply. Otherwise, the home agent MUST set the Home Agent field in the Registration Reply to its unicast address. In this latter case, the home agent MUST Kulkarni, Patel, Leung Expires July 20, 2003 [Page 12] Internet Draft Dynamic HA Assignment 20 January 2003 reject the registration with a suitable code (e.g. Code 136) to prevent the mobile node from possibly being simultaneously registered with two or more home agents. This relates to cases #2 and #4 in the table above. This framework proposes a subtle difference in behavior for case #2 above from RFC 3344. As per the framework proposed here, the mobile node (or the foreign agent) sends the Registration Request to the Directed HA address, which is a unicast address to the home agent. Because HA does not receive Registration Request that is sent to the subnet-directed broadcast address, 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 avoids the problem associated with subnet- directed broadcast destination IP address that may result in multiple HAs responding. Thus, there is no need to deny the registration as stated in RFC 3344 section 3.8.3.2. When the destination IP address is a unicast address and Home Agent field is ALL-ZERO-ONE-ADDR, the HA accepts/denies registration and sets HA field to its own IP address in the reply (i.e. registration is not rejected with error code 136). Otherwise, HA processes registration in accordance to RFC 3344. NAI extension is used for home address assignment. The Assigned HA performs standard validity checks on the Registration Request. If there is any error, the Registration Request is rejected with error codes specified in RFC 3344. 5.4 Directed Home Agent Selection The destination IP address of the first Registration Request in the Mobile IP session is the Directed HA. This address MUST be a unicast IP address. The details on how to select the Directed HA are outside the scope of this draft. However, some possible ideas are briefly covered in this section. There can be more methods for selecting the HA to the MN. Here is a high level overview of some possibilities: DHCP: MN performs DHCP to obtain an IP address on the visited network. The Directed HA is learned from the DHCP Mobile IP Home Agent Option 68 [4]. MN sends Registration Request directly to the HA and receives the Assigned HA to be used for the remainder of the Mobile IP session. Kulkarni, Patel, Leung Expires July 20, 2003 [Page 13] Internet Draft Dynamic HA Assignment 20 January 2003 AAA: MN performs challenge/response [5] with the FA. The FA retrieves the Directed HA from the AAA server and forwards the Registration Request directly to the Directed HA. The Assigned HA sends Registration Reply to the FA, which relays it to the MN. MN uses the Assigned HA for the remainder of the Mobile IP session. DNS: In this case hostname of HA is configured on MN. MN performs DNS lookup on the HA hostname. The DNS infrastructure provides resource record with information to identify the nearest HA to the MN. The MN sends Registration Request directly to the HA and receives the Assigned HA to be used for remainder of the Mobile IP session. Static configuration: Directed HA address is statically configured on MN. The MN uses the configured address to send the Registration Request. 5.5 Assigned Home Agent Selection The details on how to select the Assigned HA are outside the scope of this draft. The selection depends upon network deployment and the network requirements. For example, a large network can deploy several Assigned HAs and an optimal Assigned HA is selected by the Directed HA. The selection may be based upon optimizing the load of mobility processing. 6. Error Values Each entry in the following table contains the name and value for the error code to be returned in a Registration Reply. It also includes the section in which the error code is first mentioned in this document. Error Name Value Section Description ---------- ----- ------- ----------------------------- NONZERO-HA-REQD XX 5.2 Non-zero HA address required in Registration Request. 7. IANA Considerations The code values defined in Section 6 correspond to error values conventionally associated with the rejection by the foreign Kulkarni, Patel, Leung Expires July 20, 2003 [Page 14] Internet Draft Dynamic HA Assignment 20 January 2003 agent (i.e. value in the range 64-127). IANA should record the values as defined in Section 6. 8. Security Considerations There is no change in security of the Mobile IP protocol as defined in RFC 3344. Home agent authenticates Registration Request from the mobile node as normal. The MN also authenticates the Registration Reply from the Assigned HA, thus the existing trust model in RFC 3344 is maintained. 9. Backward Compatibility Considerations Legacy Home Agent: Legacy home agents may reject the Registration Request with error code 136 because the Home Agent field is not a unicast address. However, some legacy HA implementations may coincidentally process the Registration Request in accordance with this draft, when the HA field in RRQ is set to ALL-ZERO- ONE-ADDR. Legacy Foreign Agent: Legacy foreign agents may forward Registration Request with home agent field set to ALL-ZERO-ONE-ADDR by setting the destination IP address to ALL-ZERO-ONE-ADDR. This will result packet being dropped or incidentally handled by a next hop HA, adjacent to the FA. Legacy Mobile Node: MN that does not set HA field to ALL-ZERO-ONE-ADDR will continue to achieve its registrations through statically configured HA. In collocated mode, the endpoint of the MN's tunnel is the Assigned HA, which may not be the Directed HA address. 10. Intellectual Property Rights 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 Kulkarni, Patel, Leung Expires July 20, 2003 [Page 15] Internet Draft Dynamic HA Assignment 20 January 2003 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. 11. Acknowledgements The authors would like to thank Mike Andrews, Madhavi Chandra and Yoshi Tsuda for their review and suggestions. 12. References [1] C. Perkins, "IP Mobility Support for IPv4", RFC 3344, August 2002. [2] P. Calhoun and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000. [3] D. Senie, "Changing the Default for Directed Broadcasts in Routers", RFC 2644, August 1999. [4] S. Alexander and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [5] C. Perkins and P. Calhoun, "Mobile IPv4 Challenge/Response Extensions", RFC 3012, November 2000. Authors' Addresses Milind Kulkarni Cisco Systems Inc. 170 W. Tasman Drive, San Jose, CA 95134 USA Email: mkulkarn@cisco.com Phone:+1 408-527-8382 Alpesh Patel Cisco Systems Inc. 170 W. Tasman Drive, San Jose, CA 95134 USA Kulkarni, Patel, Leung Expires July 20, 2003 [Page 16] Internet Draft Dynamic HA Assignment 20 January 2003 Email: alpesh@cisco.com Phone:+1 408-853-9580 Kent Leung Cisco Systems Inc. 170 W. Tasman Drive, San Jose, CA 95134 USA Email: kleung@cisco.com Phone: +1 408-526-5030 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Kulkarni, Patel, Leung Expires July 20, 2003 [Page 17]