Network Working Group S. Krishnan Internet-Draft S. Touati Intended status: Informational Z. Qiang Expires: August 16, 2008 Ericsson February 13, 2008 Redirecting Binding Updates in MIPv6 draft-krishnan-mext-ha-redirect-00 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 August 16, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document specifies a new Home Agent Redirect mechanism, where an initially contacted Home Agent can let the Mobile Node knows that it needs to connect to an alternate Home Agent to get mobility services for overload prevention and/or load balancing purposes. This document proposes a new error code for the binding acknowledgement message and a new mobility option to be carried on the binding acknowledgement message for this purpose. Krishnan, et al. Expires August 16, 2008 [Page 1] Internet-Draft MIPv6 HA Redirect February 2008 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Proposed method . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Alternate HA List Option . . . . . . . . . . . . . . . . . . . 4 5. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 6 6. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . . 6 7. Applicability to PMIPv6 . . . . . . . . . . . . . . . . . . . . 7 8. Operational Considerations . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 11. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Krishnan, et al. Expires August 16, 2008 [Page 2] Internet-Draft MIPv6 HA Redirect February 2008 1. Requirements notation 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 [RFC2119]. 2. Introduction In MIPv6 [RFC3775], home agents are responsible for the registration of mobile nodes in the home network, intercepting packets destined for them, and tunneling these packets to their care-of address. When the home agent has to support a large number of mobile nodes and actively tunnel traffic to them, it could become overloaded, leading to dropped packets and connections. Dynamic Home Agent Address Discovery (DHAAD) can be used to find another home agent, but the mobile node does not know whether it must attempt this method until it encounters problems contacting its current home agent. A home agent might not want to accept any new bindings of mobile nodes other than the ones it is currently supporting, for various reasons. i.e., it might be overloaded, it wants to achieve better load balancing with another home agent in the same network, or it has some scheduled maintenance coming up soon. [RFC5142] provides a mechanism that allows a Home Agent to signal the Mobile Node that it should contact a new Home Agent, but this mechanism can only be used if the Mobile Node is already attached with the source Home Agent. There is currently no mechanism that allow a Mobile Node to be redirected to another Home Agent prior to the establishment of a binding. 3. Proposed method When a home agent receives a BU message from an MN and is not able to serve the MN, it sends a BA message back with an error code describing the cause for why it cannot accept the binding. Along with the status code, the HA optionally includes a mobility option called the Alternate HA list, that contains a list of HA addresses that the MN can contact to obtain mobility service. The method by which the alternate HA list is created on the HA is out of scope of this document. There are many ways by which this could be created. It could be done using manual configuration, listening to RAs with the Home Agent bit set etc. A new status code is defined in this document. The MIPV6-HA-REDIRECT status code is used when the HA wishes to redirect the MN. Krishnan, et al. Expires August 16, 2008 [Page 3] Internet-Draft MIPv6 HA Redirect February 2008 4. Alternate HA List Option This document defines a new mobility option called the Alternate HA List Option. This option MUST be used only in BA messages sent from a HA towards the MN. This option SHOULD be present if the status code is MIPV6-HA-REDIRECT. It MUST NOT be present if the status code is neither of the above. Krishnan, et al. Expires August 16, 2008 [Page 4] Internet-Draft MIPv6 HA Redirect February 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num HAs | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : : : HA1 Address : : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : : : HA2 Address : : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : : : HAn Address : : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBA3 Option Length Length of the Alternate HA List mobility option. Num HAs Number of HA addresses in the following list Reserved This field MUST be set to zero and ignored on reception HA1 Address 128 bit address of the first home agent HAn Address 128 bit address of the nth home agent Krishnan, et al. Expires August 16, 2008 [Page 5] Internet-Draft MIPv6 HA Redirect February 2008 Figure 1: Alternate HA List Option Format 5. Home Agent Operation Upon receiving a Binding Update message from a correspondent node, the Home Agent may reject the binding and provide a list of alternate Home Agents. This may be done for various reasons like administrative, load balancing, or policy reasons as described earlier. The HA MUST prepare a Binding Acknowledgment message, as described in [RFC3775], with a status code MIPV6-HA-REDIRECT. The HA needs to be aware of alternate HAs that can serve the MN, it MUST include an Alternate HA List option containing the addresses of the alternate HAs. 6. Mobile Node Operation Upon receiving the Binding Acknowledgment from the HA with the status code set to MIPV6-HA-REDIRECT, the Mobile node SHOULD parse the Alternate HA List Option, and extract the IPv6 addresses of the Home Agent(s). The Mobile Node MUST then establish a Security Association and send a Binding Update message to the first HA address received in the Alternate HA List Option, containing the same information as the initial BU message. If the connection to the alternate HA fails and the Status code not MIPV6-HA-REDIRECT, the Mobile node MUST select, if available, the next HA address received in the initial BA message. This process continues until the exhaustion of the list of IPv6 Home Agents. If the Mobile Node receive a Binding acknowledgment message from an alternate Home Agent with status code MIPV6-HA-REDIRECT, then this newly received list of HAs MUST override the previously received one. The Mobile Node MUST select the first HA in the newly received list, and send it a Binding Update message. In general, each time a new redirect is received by the MN it will override the previously received redirect(s) if any and the MN always acts only upon the latest Alternate HA List. Krishnan, et al. Expires August 16, 2008 [Page 6] Internet-Draft MIPv6 HA Redirect February 2008 7. Applicability to PMIPv6 The redirection procedure described in this document can also be applied to PMIPv6. The LMA MAY redirect the MAG to one or more alternate LMAs by using the same procedure on a Proxy Binding Acknowledgment message. The MAG upon receiving the PBA with the redirect SHOULD then send a PBU to the first alternate LMA returned. Every Redirect the MAG receives from an LMA overrides the previously received Redirect(s). 8. Operational Considerations In case the Redirect Mobility Option is used for redirect purposes, the potential HA that can be returned to a Mobile Node MUST be able to handle the Home Prefix of the Home Address of the Mobile Node. There could be a limit to how many redirects can be accepted by a Mobile Node before it gives up. This can be configured into the Mobile Node. This doesn't preclude the Home Agent from sending the Redirect Mobility Option. It is possible that two or more HAs can send redirects that can send an MN on a loop. This can be avoided by careful configuration of the network. A protocol based solution is possible but will unnecessarily complicate the MN. 9. IANA Considerations This document requests the assignment of the following status code from the Mobile IPv6 parameters Status Codes registry located at http://www.iana.org/assignments/mobility-parameters . TBA2 MIPV6-HA-REDIRECT This also requests the assignment of the following option code from the Mobile IPv6 parameters Mobility Options registry located at http://www.iana.org/assignments/mobility-parameters . TBA3 Alternate HA List 10. Security Considerations This document specifies an option in the binding acknowledgement message that redirects the MN towards another HA. A malicious or Krishnan, et al. Expires August 16, 2008 [Page 7] Internet-Draft MIPv6 HA Redirect February 2008 compromised HA can send this message to redirect an MN towards a possibly unavailable set of HA addresses. 11. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility Header Home Agent Switch Message", RFC 5142, January 2008. Authors' Addresses Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada Phone: +1 514 345 7900 x42871 Email: suresh.krishnan@ericsson.com Samy Touati Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada Phone: +1 514 345 7900 x42366 Email: samy.touati@ericsson.com Zu Qiang Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada Phone: +1 514 345 7900 x47370 Email: zu.qiang@ericsson.com Krishnan, et al. Expires August 16, 2008 [Page 8] Internet-Draft MIPv6 HA Redirect February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST 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 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Krishnan, et al. Expires August 16, 2008 [Page 9]