Network Working Group S. Krishnan Internet-Draft S. Touati Intended status: Informational Z. Qiang Expires: August 28, 2008 Ericsson February 25, 2008 Redirecting Proxy Binding Updates in PMIPv6 draft-krishnan-mext-ha-redirect-01 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 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document specifies a new LMA Redirect mechanism, where an initially contacted LMA can let the MAG know that it needs to connect to an alternate LMA to get mobility services, either for overload prevention and/or load balancing purposes. This document proposes a new error code for the proxy binding acknowledgement message and a new mobility option to be carried on the binding acknowledgement message for this purpose. Krishnan, et al. Expires August 28, 2008 [Page 1] Internet-Draft PMIPv6 LMA Redirect February 2008 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Proposed method . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Alternate LMA List Option . . . . . . . . . . . . . . . . . . . 3 5. LMA Operation . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. MAG Operation . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Operational Considerations . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 10. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Krishnan, et al. Expires August 28, 2008 [Page 2] Internet-Draft PMIPv6 LMA 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 PMIPv6 [PMIPv6], LMAs are responsible for the registration of mobile nodes in the home network, intercepting packets destined for them, and tunneling these packets to their proxy care-of address hosted on a MAG. When the LMA 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. An LMA 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 known LMA 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 it is not clear if this mechanism can be used for PMIPv6 in the interaction between the MAG and the LMA. 3. Proposed method When an LMA receives a PBU message from a MAG and is not able to serve the MN specified in the PBU, it sends a PBA message back with an error code describing the cause for why it cannot accept the binding. Along with the status code, the LMA optionally includes a mobility option called the Alternate LMA list, that contains a list of LMA addresses that the MAG can contact to obtain mobility service for the MN. The method by which the alternate LMA list is created on the LMA is out of scope of this document. A new status code is defined in this document. The PMIPV6-LMA- REDIRECT status code is used when the LMA wishes to redirect the MAG. 4. Alternate LMA List Option This document defines a new mobility option called the Alternate LMA List Option. This option MUST be used only in PBA messages sent from a LMA towards the MAG. This option SHOULD be present if the status Krishnan, et al. Expires August 28, 2008 [Page 3] Internet-Draft PMIPv6 LMA Redirect February 2008 code is PMIPV6-LMA-REDIRECT. It MUST NOT be present if the status code is not PMIPV6-LMA-REDIRECT. Krishnan, et al. Expires August 28, 2008 [Page 4] Internet-Draft PMIPv6 LMA 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 LMAs | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : : : LMA1 Address : : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : : : LMA2 Address : : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : : : LMAn Address : : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBA3 Option Length Length of the Alternate LMA List mobility option. Num LMAs Number of LMA addresses in the following list Reserved This field MUST be set to zero and ignored on reception LMA1 Address 128 bit address of the first LMA LMAn Address 128 bit address of the nth LMA Krishnan, et al. Expires August 28, 2008 [Page 5] Internet-Draft PMIPv6 LMA Redirect February 2008 Figure 1: Alternate LMA List Option Format 5. LMA Operation Upon receiving a Proxy Binding Update message from a MAG, the LMA may reject the binding and provide a list of alternate LMAs. This may be done for various reasons like administrative, load balancing, or policy reasons as described earlier. The LMA MUST prepare a Proxy Binding Acknowledgment message, as described in [PMIPv6], with a status code PMIPV6-LMA-REDIRECT. The LMA needs to be aware of alternate LMAs that can serve the MN, and it MUST include an Alternate LMA List option containing the addresses of the alternate LMAs. 6. MAG Operation Upon receiving the Proxy Binding Acknowledgment from the LMA with the status code set to PMIPV6-LMA-REDIRECT, the MAG SHOULD parse the Alternate LMA List Option, and extract the IPv6 addresses of the LMA(s). The MAG MUST then send a Proxy Binding Update message to the first LMA address received in the Alternate LMA List Option, containing the same information as the initial PBU message. If the connection to the alternate LMA fails and the Status code is not PMIPV6-LMA-REDIRECT, the Mobile node MUST select, if available, the next LMAA address received in the initial PBA message. This process continues until the exhaustion of the list of LMAs. If the MAG receives a Proxy Binding acknowledgment message from an alternate LMA with status code PMIPV6-LMA-REDIRECT, then this newly received list of LMAs MUST override the previously received one. The MAG MUST select the first LMA in the newly received list, and send it a Proxy Binding Update message. In general, each time a new redirect is received by the MAG it will override the previously received redirect(s) if any and the MAG always acts only upon the latest Alternate LMA List. 7. Operational Considerations In case the Redirect Mobility Option is used for redirect purposes, the potential LMA that can be returned to a MAG MUST be able to Krishnan, et al. Expires August 28, 2008 [Page 6] Internet-Draft PMIPv6 LMA Redirect February 2008 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 MAG before it gives up. This can be configured on the MAG. This doesn't preclude the LMA from sending the Redirect Mobility Option. It is possible that two or more LMAs can send redirects that can send an MAG on a loop. This can be avoided by careful configuration of the network. A protocol based solution is possible but will unnecessarily complicate the MAG. 8. 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 PMIPV6-LMA-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 LMAA List 9. Security Considerations This document specifies an option in the proxy binding acknowledgement message that redirects the MAG towards another LMA. A malicious or compromised LMA can send this message to redirect an MAG towards a possibly unavailable set of LMA addresses. 10. Normative References [PMIPv6] Gundavelli, S., "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-11 (work in progress), March 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility Header Home Agent Switch Message", RFC 5142, January 2008. Krishnan, et al. Expires August 28, 2008 [Page 7] Internet-Draft PMIPv6 LMA Redirect February 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 28, 2008 [Page 8] Internet-Draft PMIPv6 LMA 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 28, 2008 [Page 9]