Mobile IPv4 M. Jin Internet-Draft M. Wang Expires: January 12, 2006 China Unicom H. Deng Hitachi B. Haley Hewlett-Packard Company July 11, 2005 Mobile IPv4 Home Agent Switch Message draft-jin-mip4-ha-switch-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on January 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract RFC 3344 [2] contains no provision to allow a home agent to inform a mobile node that it needs to stop acting as the home agent for the mobile node. Dynamical Home Agent assignment [3] is designed for assigning a optimal home agent for mobile node, not for proactively Jin, et al. Expires January 12, 2006 [Page 1] Internet-Draft HA Switch Message for MIPv4 July 2005 notifying a mobile node to change it's home agent. This document specifies a new MIP4 control message that can be used between a home agent and mobile node to signal a mobile node that it should acquire a new home agent. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Home Agent Switch Message . . . . . . . . . . . . . . . . . . 3 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Home Agent Operation . . . . . . . . . . . . . . . . . . . 4 3.2 Foreign Agent Operation . . . . . . . . . . . . . . . . . 5 3.3 Mobile Node Operation . . . . . . . . . . . . . . . . . . 5 4. Operational Considerations . . . . . . . . . . . . . . . . . . 5 5. Procotol Constants . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1 Normative References . . . . . . . . . . . . . . . . . . . 6 8.2 Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . 8 Jin, et al. Expires January 12, 2006 [Page 2] Internet-Draft HA Switch Message for MIPv4 July 2005 1. Introduction IP Mobility support for IPv4 RFC 3344 [2] contains no provision to allow a home agent to inform a mobile node that it needs to stop acting as the home agent for the mobile node. Dynamical Home Agent assignment [3] defined a messaging mechanism where mobile node can request and receive a dynamic HA address in Mobile IPv4 messages. But if a home agent goes offline or is overloaded, the process to change to a new home agent based on this mechanism could be slow since this event it transparent to the mobile node. This document specifies a new MIP4 control message that can be used between a home agent and mobile node to signal a mobile node that it should acquire a new home agent. There are many cases where this message can be used, for example, a home agent may wish to handoff some of its mobile nodes to another home agent because it has become overloaded or it is going offline. some of these has been mentioned already in [4]. 2. Home Agent Switch Message Mobile IP has already defined a set of new control messages, sent with UDP using well-known port number 434. Registration Request and Registration Reply type have been defined as 1 and 3. Here we define a new type 5 for Home Agent Switch Message IP fields: Source Address Home agent's address. Destination Address Mobile node's address. UDP fields: Source Port Destination Port 434. The UDP header is followed by the Mobile IP fields shown below: Jin, et al. Expires January 12, 2006 [Page 3] Internet-Draft HA Switch Message for MIPv4 July 2005 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | # of addrs | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Addresses | + + . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Type 5 (Home Agent Switch) # of Addresses A 8-bits unsigned integer indicating the number of IPv6 home agent addresses in the message. If set to zero, the mobile node MUST perform dynamical home agent assignment. Reserved 16-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Home Agent Addresses A list of alternate home agent addresses on the home link for the mobile node. The number of addresses present in the list is indicated by the "# of Addresses" field in the Home Agent Switch message. 3. Operations 3.1 Home Agent Operation A home agent SHOULD send a Home Agent Switch message when a known period of unavailability is pending so the mobile node has sufficient time to find another suitable home agent. If the home agent does not receive a response from the mobile node (a Registration Request message to delete its mobility binding), then it SHOULD retransmit the message, until a response is received. The initial value for the retransmission timer is INITIAL_HA_SWITCH_TIMEOUT. The retransmissions by the home agent Jin, et al. Expires January 12, 2006 [Page 4] Internet-Draft HA Switch Message for MIPv4 July 2005 MUST use an exponential back-off mechanism, in which the timeout period is doubled upon each retransmission, until either the home agent gets a response from the mobile node to delete its binding, or the timeout period reaches the value MAX_HA_SWITCH_TIMEOUT. Attempts by the mobile node to extend the mobility binding lifetime with a registration request message SHOULD be rejected, and a registration reply SHOULD be returned with status value 129 (Administratively prohibited) as specified in [2]. 3.2 Foreign Agent Operation A foreign agent SHOULD only forward this message directly to mobile node without any modification. 3.3 Mobile Node Operation Upon receiving a Home Agent Switch message, The packet MUST be covered by the home agent to mobile node IPsec ESP authentication SA for integrity protection. Upon receipt of a Home Agent Switch message, the mobile node MUST stop using its current home agent for services and MUST delete its home registraiton in home agent's mobility binding list by sending a Registration Request message. This acts as an acknowledgement of the Home Agent Switch message. If the Home Agent Switch message contains a list of alternate home agent addresses, the mobile node SHOULD select a home agent at random. If no alternate home agent addresses are included in the list, the mobile node MUST first perform dynamical home agent assignment. If a mobile node is unreachable, for example in idle state, when home agent send home agent switch message to mobile node, mobile node can not response back. In this case, the home agent SHOULD NOT make any conclusions about its status. After this mobile node recover from idle state, it found that previous registered home agent is not available, it can find a new home agent based on the mechanism of dynamical home agent assignment [2]. 4. Operational Considerations This document does not specify how an operator might use the Home Agent Switch message in its network. However, it might be the case that a home agent provides service for many thousands of mobile nodes. Care should be taken to reduce the signaling overhead required for handing off many mobile nodes to an alternate home Jin, et al. Expires January 12, 2006 [Page 5] Internet-Draft HA Switch Message for MIPv4 July 2005 agent. 5. Procotol Constants INITIAL_HA_SWITCH_TIMEOUT 5 seconds MAX_HA_SWITCH_TIMEOUT 20 seconds 6. IANA Considerations Mobile IP messages are defined to be those that are sent to a message recipient at port 434 (UDP or TCP). The currently standardized message types have the following numbers, and are specified in the indicated sections. Type Name ---- ------------------------- 5 Home Agent switch message 7. Security Considerations The Home Agent Switch message MUST use mobile-home authentication extension which is defined in section 3.5.2 of [2], Exactly one authorization-enabling extension MUST be present in all the Home Agent switch message. 8. References 8.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. 8.2 Informative References [3] Kulkarni, M., "Mobile IPv4 Dynamic Home Agent Assignment", draft-ietf-mip4-dynamic-assignment-04 (work in progress), May 2005. [4] Haley, B., "Mobility Header Home Agent Switch Message", draft-haley-mip6-ha-switch-00 (work in progress), April 2005. Jin, et al. Expires January 12, 2006 [Page 6] Internet-Draft HA Switch Message for MIPv4 July 2005 Authors' Addresses Mingye Jin China Unicom Beijing 100032 China Email: jinmy@chinaunicom.com.cn Minghui Wang China Unicom Beijing 100032 China Email: wangmh@chinaunicom.com.cn Hui Deng Hitachi Beijing Fortune Bldg. 1701 5 Dong San Huan Bei-Lu Chao Yang District Beijing 100004 China Email: hdeng@hitachi.cn Brian Haley Hewlett-Packard Company 110 Spitbrook Road Nashua NH 03062 USA Email: brian.haley@hp.com Jin, et al. Expires January 12, 2006 [Page 7] Internet-Draft HA Switch Message for MIPv4 July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 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 (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jin, et al. Expires January 12, 2006 [Page 8]