Mobile IPv6 J. Kempf Internet Draft DoCoMo USA Labs Expires: October,2005 Feburary, 2005 Extension to RFC 3775 for Alerting the Mobile Node to Home Agent Unavailability draft-kempf-mip6-ha-alert-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable 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 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 July 28, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract RFC 3775 contains no way for a home agent to notify a mobile node that the home agent will shortly become unavailable, and suggest possible substitutes. A mobile node can suddenly find itself without mobility service. This document describes a simple protocol to inform the mobile node when its home agent is about to become unavailable Kempf Expires October, 2005 Page [1] Internet-Draft Home Agent Unavailability Alerting Feburary, 2005 and whether the mobile node should re-run bootstrapping to find a new home agent. Conventions used in this document 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 [1]. Table of Contents 1. Introduction...................................................2 2. Scenarios......................................................3 2.1. Periodic Maintenance......................................3 2.2. Functional Load Balancing.................................3 2.3. Home Agent Renumbering....................................4 3. Home Agent Unavailability Message..............................4 3.1. Validation of HAU Messages................................4 3.2. Home Agent Unavailability Message Format..................5 4. Home Agent Considerations......................................6 5. Mobile Node Considerations.....................................6 6. Security Considerations........................................7 7. Open Questions.................................................7 8. References.....................................................8 8.1. Normative References......................................8 8.2. Informative References....................................8 Author's Addresses................................................8 Intellectual Property Statement...................................8 Disclaimer of Validity............................................9 Copyright Statement...............................................9 Acknowledgment....................................................9 1. Introduction RFC 3775 [2] contains no protocol to allow a home agent to inform its mobile nodes that it is about to cease service. Without such functionality, a mobile node can suddenly find itself without its tunneled traffic. Even worse, if the mobile node is route optimizing, it may not discover the problem until much later, after other nodes fail to contact it. Note that, as a router on the home link, the home agent can use an unmodified RFC 2461 [2] Redirect to tell the mobile node about a new router on the home link, but the message is ambiguous. Is the recommended router a home agent or it just a router only for nodes on the home link? What if the entire link is going down? RFC 2461 only Kempf Expires October, 2005 [Page 2] Internet-Draft Home Agent Unavailability Alerting Feburary, 2005 allows routers to be referred to by their link local address in Redirects, which would not allow a mobile node away from home to find the new home agent. A home agent can also send a Router Advertisement with lifetime zero to indicate that it was becoming unavailable, but this would not provide the mobile node with any indication of a suggested substitute. In this document, a simple extension of the RFC 3775 Home Agent Discovery message is proposed to allow home agent unavailability alerting. The extension allows a home agent to send an unsolicited Home Agent Discovery message to inform the mobile node about the need to find a new home agent. 2. Scenarios Here are a few sample scenarios where a home agent unavailability alerting message would be useful. 2.1. Periodic Maintenance Although many users and engineers would prefer that networking equipment run without ever shutting down, most responsible service providers do periodic maintenance in order to maintain reliability. If a home agent is shut down for maintenance, some way is required to tell the client mobile nodes so they don't lose mobility service. 2.2. Functional Load Balancing A Mobile IPv6 home agent provides the client with two basic services: a rendezvous server where correspondents can find the current care of address for the mobile node, and - when route optimization isn't used - an overlay router to redirect traffic sent to/from the home address to/from the care of address. A mobility service provider could have two sets of home agents to handle the two functions. The rendezvous function could be handled by a machine specialized for high speed transaction processing, while the overlay router function could be handled by a machine with high data throughput. A mobile node would start on the rendezvous server-like home agent and stay there if it does route optimization. However, if the original home agent detects that the mobile node isn't doing route optimization, it could redirect the mobile node to a home agent with better data throughput (of course, any existing TCP sessions would be dropped). Kempf Expires October, 2005 [Page 3] Internet-Draft Home Agent Unavailability Alerting Feburary, 2005 2.3. Home Agent Renumbering Periodically, a mobility service provider may want to shut down home agent service at a set of IPv6 addresses and bring service back up at a new set of addresses. Note that this may not involve anything as complex as IPv6 network renumbering, it may just involve changing the addresses on the home agents. There are various reasons why a mobility service provider might want to do this; an example is if the mobility service provider revokes the account of a user who the service provider has reason to believe might use the old home agent address to disrupt service for other users. With a service unavailability message, the service provider could inform mobile nodes to look for a new home agent. 3. Home Agent Unavailability Message A home agent sends a Home Agent Unavailability (HAU) message when an anticipated period of unavailability occurs for the home agent. The message is sent to the mobile node's home address and is tunneled to the mobile node at its care of address. 3.1. Validation of HAU Messages A mobile node MUST silently discard a received HAU message that does not satisfy all of the following validity checks: - IP Source Address is the global home agent address - The message is covered by the IPsec ESP SAs for ICMP messages between the home agent and mobile node. - IP Destination Address is the mobile node's home address. - ICMP Checksum is valid. - ICMP Code is TBD. - ICMP length (derived from the IP length) is 8 or more octets. - All included options have a length that is greater than zero. The contents of the Reserved field, and of any unrecognized options MUST be ignored. Kempf Expires October, 2005 [Page 4] Internet-Draft Home Agent Unavailability Alerting Feburary, 2005 3.2. Home Agent Unavailability Message Format Home agents send HAU packets to inform mobile node clients about pending periods of unavailability. The home agent can recommend a list of substitute home agent addresses, or it can require the mobile node to re-initiate bootstrapping to find a new home agent by setting the length of the substitute list to zero. 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Number of Addresses | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + Home Agent Address List... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address MUST be the home agent's global address. Destination Address MUST be the mobile node's home address. ESP Header The packet MUST be protected by an ESP tunnel mode header for data origin authentication and encryption, used to protect ICMP packets between the home agent and mobile node. ICMP Fields: Type 145 Kempf Expires October, 2005 [Page 5] Internet-Draft Home Agent Unavailability Alerting Feburary, 2005 Code TBD (assigned by IANA) Checksum The ICMP checksum Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Number of Addresses An unsigned integer giving the number of IPv6 home agent addresses in the list to follow. If zero, then the mobile node MUST redo home agent discovery. Home Agent Address List List of 128 bit IPv6 addresses for suggested substitute home agents. Possible Options: There are no default options. Options can be added by extension. 4. Home Agent Considerations A home agent SHOULD send a HAU message when a known period of unavailability is pending. The message MUST be sent to all mobile nodes with currently active bindings. If alternative home agent addresses are known, either on the same subnet or a different one, the home agent SHOULD include them in the list of suggested substitute home agents. Otherwise, the home agent MUST set the length of the substitute home agent list to zero, forcing the mobile node to perform home agent discovery by some other means. 5. Mobile Node Considerations Upon receipt of a HAU message, a mobile node MUST cease utilizing the old home agent for overlay traffic routing. If the HAU message contains a list of substitute home agents, the mobile node SHOULD select a home agent at random and establish the necessary IPsec security associations with the new home agent by whatever means required as part of the mobile node/home agent bootstrapping protocol for the home agent's mobility service provider. If no substitute home agents are included in the list, the mobile node MUST first perform home agent discovery. Kempf Expires October, 2005 [Page 6] Internet-Draft Home Agent Unavailability Alerting Feburary, 2005 6. Security Considerations As with other home link ICMP messages in RFC 3775, the HAU message MUST use the home agent to mobile node ESP encryption SA for confidentiality protection, and MUST use the home agent to mobile node ESP authentication SA for integrity protection. IANA Considerations A new ICMP Code, TBD, is required for the ICMP Home Agent Discovery message, type 145. 7. Open Questions - If a home agent has a lot of clients, the IKE traffic and binding updates to the new home agent or agents could result in a lot of congestion. Would it make sense to enable a mode whereby the home agent can transfer the security and binding context to the new home agents, then set a flag in the HAU so that the mobile nodes don't have to re-initialize? Generally, transferring IPsec between hosts ("outside the crypto boundary") is strongly frowned upon by security folks, but one could make an argument that a distributed crypto boundary in which the machines share a strong security association could be set up. The other problem is what new home address to use. One could specify something simple, like the old interface identifier plus subnet prefix from the new home agent subnet, but that disallows subtle address allocation strategies such as CGA or RFC 3041 address privacy. All in all, it seems like a hack. Sme kind of timing randomization on the initialization traffic would reduce the potential for congestion, but not the overall traffic volume. - If a home agent has lots of clients, it could end up unicasting lots of HAU messages, which could result in a lot of traffic and thus congestion. Would it make more sense to use a multicast message, perhaps to the All Nodes Multicast Address? Or should we introduce an All Mobile Nodes Multicast Address to avoid having fixed nodes on the subnet get the message? If multicast is used, then what security is on the packet? IPsec is for unicast only, so the ICMP SA can't be used. - Should the HAU include a "remaining lifetime" field, indicating how long the mobile node has before the home agent becomes unavailable? Kempf Expires October, 2005 [Page 7] Internet-Draft Home Agent Unavailability Alerting Feburary, 2005 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] Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in IPv6", RFC 3775, June, 2004. [3] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998 8.2. Informative References Author's Addresses James Kempf DoCoMo USA Labs 181 Metro Drive Suite 300 San Jose, CA 95110 Phone: +1 408 451 4711 Email: kempf@docomolabs-usa.com 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. Kempf Expires October, 2005 [Page 8] Internet-Draft Home Agent Unavailability Alerting Feburary, 2005 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. By submitting this Internet-Draft, I certify that any applicable 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. 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 (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kempf Expires October, 2005 [Page 9]