NETLMM Working Group V. Devarapalli Internet-Draft WiChorus Intended status: Standards Track October 27, 2008 Expires: April 30, 2009 Separating Control and Data Plane for Proxy Mobile IPv6 draft-devarapalli-netlmm-pmipv6-data-plane-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 April 30, 2009. Abstract Proxy Mobile IPv6 is a network-based mobility management protocol. The mobility entities involved in the Proxy Mobile IPv6 protocol, the Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA), setup tunnels dynamically to manage mobility for a mobile node within the Proxy Mobile IPv6 domain. This document describes an extension to the Proxy Mobile IPv6 protocol to register a data plane address, that is different from the Proxy Care-of Address with the LMA. This allows separation of control and data plane. Devarapalli Expires April 30, 2009 [Page 1] Internet-Draft PMIPv6 Data Plane Option October 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Control and Data Plane Separation . . . . . . . . . . . . . . . 4 3.1. Extensions to Binding Update List and Binding Cache Data Structures . . . . . . . . . . . . . . . . . . . . . . 5 4. Data Plane Address Mobility Option . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Devarapalli Expires April 30, 2009 [Page 2] Internet-Draft PMIPv6 Data Plane Option October 2008 1. Introduction Proxy Mobile IPv6 [2] enables network-based mobility for IPv6 hosts that do not implement any mobility protocols. The protocol is described in detail in [2]. In order to facilitate the network-based mobility, the PMIPv6 protocol defines a Mobile Access Gateway (MAG), which acts as a proxy for the Mobile IPv6 [4] signaling, and the Local Mobility Anchor (LMA) which acts similar to a Home Agent, anchoring a Mobile Node's sessions within a Proxy Mobile IPv6 (PMIPv6) domain. The LMA and the MAG establish a bidirectional tunnel for forwarding all data traffic belonging to the Mobile Nodes. Some of the deployments of Proxy Mobile IPv6 are planning to separate the control and data plane end points for the Mobile Access Gateway. There will be a separate IP address for the entity that sends and receives the Proxy Mobile IPv6 signaling messages. Similarly, there will be a separate IP address for the entity that encapsulates and decapsulates the data traffic to/from the mobile node. According to RFC 5213 [2] and RFC 3775 [4], the LMA stores only IP address, the Proxy Care-of Address (PCOA), in the proxy binding cache entry at the LMA. Therefore the LMA uses the same IP address of a MAG for signaling messages and data traffic. In order to allow the separation of the control and data plane, this document describes an extension to register two IP addresses with the LMA. The IP address used for the signaling messages will continue to be called the Proxy Care-of Address. A separate IP address for the data plane is carried in the Proxy Binding Update to indicate the tunnel end point for the data traffic. The separation of control and data plane allows a number of scenarios. It is possible to keep the control plane end point the same for a mobile node as it moves across the MAGs in the PMIPv6 domain. The new MAG, the mobile node attaches to, is only used as the data plane end point. This helps in avoiding access authentication every time the mobile node moves and attaches to a different MAG. The mechanism described in the document also enables some load balancing scenarios, where the data traffic is directed to different application blades in a chassis-based PMIPv6 network entity implementation, with a fewer number of blades handling the control traffic. The control and data plane separation might require some interaction between the control plane and data plane end points. For example, the data plane end point would need to install some forwarding entries for the mobile node based on the PMIPv6 signaling messages exchanged by the control plane end point. Future versions of this document may specify the messages required for such an interaction. Devarapalli Expires April 30, 2009 [Page 3] Internet-Draft PMIPv6 Data Plane Option October 2008 It is out of scope for this document for now. The mechanism described in the document can be used by both the MAG and the LMA for control and data plane separation. 2. Terminology 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 [1]. 3. Control and Data Plane Separation If a MAG wants to register a separate data plane address, it MUST include the Data Plane Address mobility option described in Section 4, in the Proxy Binding Update. The MAG MUST include the IPv6 address of the data plane end point in the Data Plane Address mobility option In case there is an IPv4 transport network between the MAG and the LMA as described in [3], the MAG MUST include the IPv4 address of the data plane end point. When the LMA receives a Proxy Binding Update message with the Data Plane Address mobility option, it MUST store the address in the mobility option as the end point for the PMIPv6 tunnel created for carrying the mobile node's traffic. The source address of the Proxy Binding Update message or the address in the Alternate Care-of Address option [4], if present, is stored as the Proxy Care-of Address for the particular binding. If the Data Plane Address option was successfully processed, the LMA MUST include the Data Plane Address option in the Proxy Binding Acknowledgment message without any IP address in the mobility option. In case the LMA does not support the mechanism described in this document, it will not recognize the Data Plane Address mobility option and will skip processing the option. If the LMA recognizes the option, but does not want use separate IP addresses for the control and data planes, it MUST send a Proxy Binding Acknowledgment message with a failed status, "DATA_PLANE_SEPARATION_NOT_ALLOWED". If the MAG receives a Proxy Binding Acknowledgment message without the Data Plane mobility option in response to a Proxy Binding Update in which it had included a Data Plane Address option, it MUST conclude that the LMA does not support the separation of control and data plane. The MAG MUST then raise an alarm for an administrative action. If the MAG receives a Proxy Binding Acknowledgment message with status, "DATA_PLANE_SEPARATION_NOT_ALLOWED", it MUST NOT send any more Proxy Binding Update messages to the particular LMA and MUST Devarapalli Expires April 30, 2009 [Page 4] Internet-Draft PMIPv6 Data Plane Option October 2008 raise an alarm for an administrative action. Even though the mechanism described in this document is primarily intended for separation of control and data plane on the MAG, it is possible to use it for the LMA also. If the LMA wants to use a separate data plane address, it should include the data plane end point in the Data Plane Address mobility option in the Proxy Binding Acknowledgment message. The MAG would use this address as the LMA tunnel end point for data traffic. 3.1. Extensions to Binding Update List and Binding Cache Data Structures This document extends the Binding Update List entry on the MAG and the Binding Cache Entry on the LMA to include the data plane address in addition to the Proxy Care-of Address. The Proxy Care-of Address MUST be used for all Proxy Mobile IPv6 signaling messages, including messages initiated by the LMA like the Binding Revocation Indication message [7]. The Data Plane address MUST be used for tunneling the data traffic meant for the mobile node. 4. Data Plane Address Mobility Option The following shows the message format for a new mobility option for carrying the data plane address, or the tunnel end point. The Data Plane Address Mobility Option is only valid in a Proxy Binding Update and Proxy Binding Acknowledgment messages. It has an alignment requirement of 4n+1. 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 | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Plane Address .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type A 8-bit field that indicates that it is a Data Plane Address mobility option. Length A 8-bit field that indicates the length of the option in octets excluding the 'Type' and 'Length' fields. It is set to '5' if an IPv4 address is carried in the option. It is set to '17' if an Devarapalli Expires April 30, 2009 [Page 5] Internet-Draft PMIPv6 Data Plane Option October 2008 IPv6 address is carried in the option. If there is no address being carried in the option, i.e., it is being sent by the LMA just to acknowledge the processing of the Data Plane Address mobility option in the Proxy Binding Acknowledgment, then it is set to '1'. Reserved A 8-bit field that is set to '0' and ignored by the receiver. Data Plane Address A 32-bit or 128-bit field to carry the IPv4 or IPv6 address of the Proxy Mobile IPv6 tunnel end point. This field is absent if the LMA is sending this option in the Proxy Binding Acknowledgment messages to indicate that it processed the Data Plane Address mobility option in the preceding Proxy Binding Update message. 5. Security Considerations Since the Data Plane Address mobility option is carried in the Proxy Binding Update and Proxy Binding Acknowledgment messages, no additional security beyond what is described in RFC 5213. According to RFC 5213 [2], these messages are protected by the use of IPsec [5]. As a result of the control and data plane separation, if there is an interface with new messages between the control plane and data plane end points, the messages exchanged on this interface MUST be secured. Integrity protection is mandatory. Confidentiality protection is optional. If the messages use the Mobility Header protocol [4], it is recommended that these messages are protected by the use of IKEv2 [6] and IPsec [5]. 6. IANA Considerations The Data Plane Address mobility option defined in Section 4 must have the type value allocated from the same space as the Mobility Options defined in RFC 3775 [4]. A new Proxy Binding Ack status value from the "Status Codes" registry defined by RFC 3775 [4] should be allocated. The new status code is a failure status code, (>128) and is called "DATA_PLANE_SEPARATION_NOT_ALLOWED". Devarapalli Expires April 30, 2009 [Page 6] Internet-Draft PMIPv6 Data Plane Option October 2008 7. Acknowledgments The author would like to think the folks involved in the discussion on the NETLMM mailing list on the topic of separating the control and data plane for Proxy Mobile IPv6. 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] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [3] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-05 (work in progress), September 2008. 8.2. Informative References [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [5] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [6] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [7] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P. Yegani, "Binding Revocation for IPv6 Mobility", draft-ietf-mext-binding-revocation-01 (work in progress), August 2008. Author's Address Vijay Devarapalli WiChorus 3950 North First Street San Jose, CA 95134 USA Email: vijay@wichorus.com Devarapalli Expires April 30, 2009 [Page 7] Internet-Draft PMIPv6 Data Plane Option October 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. Devarapalli Expires April 30, 2009 [Page 8]