Internet Engineering Task Force (IETF) R. Wakikawa Request for Comments: 7389 Softbank Mobile Category: Standards Track R. Pazhyannur ISSN: 2070-1721 S. Gundavelli Cisco C. Perkins Futurewei Inc. October 2014 Separation of Control and User Plane for Proxy Mobile IPv6
AbstractThis document specifies a method to split the control plane (CP) and user plane (UP) for a network infrastructure based on Proxy Mobile IPv6 (PMIPv6). Existing specifications allow a mobile access gateway (MAG) to separate its control and user plane using the Alternate Care-of Address mobility option for IPv6 or Alternate IPv4 Care-of Address option for IPv4. However, the current specification does not provide any mechanism allowing the local mobility anchor (LMA) to perform an analogous functional split. To remedy that shortcoming, this document specifies a mobility option enabling an LMA to provide an alternate LMA address to be used for the bidirectional user-plane traffic between the MAG and LMA. With this new option, an LMA will be able to use an IP address for its user plane that is different than the IP address used for the control plane. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7389.
Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction ....................................................2 2. Conventions and Terminology .....................................5 2.1. Conventions ................................................5 2.2. Terminology ................................................5 3. Additional Fields in Conceptual Data Structures .................6 4. LMA User-Plane Address Mobility Option ..........................6 5. Protocol Configuration Variable .................................8 6. IANA Considerations .............................................9 7. Security Considerations .........................................9 8. References .....................................................10 8.1. Normative References ......................................10 8.2. Informative References ....................................10 Acknowledgements ..................................................12 Authors' Addresses ................................................12
Widely deployed mobility management systems for wireless communications require separation of IP transport for forwarding user-plane and control-plane traffic. This separation offers more flexible deployment options for LMA and MAG entities in Proxy Mobile IPv6, as described in [MOBILE-SEPARATION]. To meet this requirement would also require that the control-plane functions of the LMA be addressable at a different IP address than the IP address assigned for the user plane. However, PMIPv6 does not currently specify a mechanism for allowing the LMA to separate the control plane from the user plane. The LMA is currently required to associate the IP address of the tunnel source with the target IP address for the control messages received from the MAG. The control-plane and user-plane components of a MAG or LMA are typically co-located in the same physical entity. However, there are situations where it is desirable to have the control and user plane of a MAG or LMA in separate physical entities. For example, in a WLAN (Wireless LAN) network, it may be desirable to have the control- plane component of the MAG reside on the Access Controller (also sometimes referred to as Wireless LAN Controller (WLC)) while the user-plane component of the MAG resides on the WLAN Access Point. This enables all the control-plane messages to the LMA to be centralized while the user plane would be distributed across the multiple Access Points. Similarly, there is a need for either the control-plane or user-plane component of the LMA to be separated according to different scaling requirements or, in other cases, the need to centralize the control plane in one geographical location while distributing the user-plane component across multiple locations. For example, as illustrated in Figure 1, the LMA and MAG could have one control session established for PMIPv6 control signaling while maintaining separate connectivity via Generic Routing Encapsulation (GRE) or IP-in-IP tunneling for forwarding user-plane traffic.
MAG LMA +--------+ +--------+ +------+ | MAG-CP |--------------| LMA-CP | _----_ | MN | | | PMIPv6 | | _( )_ | |---- +--------+ +--------+ ===( Internet ) +------+ : : (_ _) +--------+ +--------+ '----' | MAG-UP |--------------| LMA-UP | | | GRE/IP-in-IP | | +--------+ /UDP +--------+ MN: Mobile Node CP: Control Plane UP: User Plane Figure 1: Functional Separation of the Control and User Plane [RFC6463] and [RFC6275] enable separating the control and user plane in the MAG. In particular, [RFC6463] defines the Alternate IPv4 Care-of Address option, and [RFC6275] defines an Alternate Care-of Address option for IPv6. The MAG may provide an Alternate Care-of Address in the PBU, and if the LMA supports this option, then a bidirectional tunnel is set up between the LMA address and the MAG's Alternate Care-of Address. However, these documents do not specify a corresponding option for the LMA to provide an alternate tunnel endpoint address to the MAG. This specification therefore defines a new mobility option that enables a local mobility anchor to provide an alternate LMA address to be used for the bidirectional tunnel between the MAG and LMA, as shown in Figure 1. The LMA control-plane and the LMA user-plane functions are typically deployed on the same IP node, and in such a scenario, the interface between these functions is internal to the implementation. Deployments may also choose to deploy the LMA control-plane and the LMA user-plane functions on separate IP nodes. In such deployment models, there needs to be a protocol interface between these two functions, but that is outside the scope of this document. Possible options for such an interface include OpenFlow [OpenFlow-Spec-v1.4.0], Forwarding and Control Element Separation (ForCES) [RFC5810], use of routing infrastructure [STATELESS-UPLANE], and vendor-specific approaches. This specification does not mandate a specific protocol interface and views this interface as a generic interface relevant more broadly for many other protocol systems in addition to Proxy Mobile IPv6. When the LMA control-plane and the LMA user-plane functions are deployed on separate IP nodes, the requirement related to user-plane address anchoring (specified in
Section 5.6.2 of [RFC5213] and Section 3.1.3 of [RFC5844]) must be met by the node hosting the LMA user-plane functionality. The LMA user-plane node must be a topological anchor point for the IP address/prefixes allocated to the mobile node. RFC2119]. RFC6459]. Other mobility-related terms used in this document are to be interpreted as defined in [RFC5213] and [RFC5844]. Additionally, this document uses the following terms: IP-in-IP IP-within-IP Encapsulation [RFC2473] [RFC4213]. GRE Generic Routing Encapsulation [RFC1701]. UDP Encapsulation Encapsulation mode based on UDP transport specified in [RFC5844]. LMA Control-Plane Address (LMA-CPA) The IP address on the LMA that is used for sending and receiving control-plane traffic from the MAG. LMA User-Plane Address (LMA-UPA) The IP address on the LMA that is used for sending and receiving user-plane traffic from the MAG. MAG Control-Plane Address (MAG-CPA) The IP address on the MAG that is used for sending and receiving control-plane traffic from the LMA.
MAG User-Plane Address (MAG-UPA) The IP address on the MAG that is used for sending and receiving user-plane traffic from the LMA. This address is also referred to as the Alternate Care-of Address. Figure 2: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | . . + LMA User-Plane Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: LMA User-Plane Address Mobility Option Format
Type 59 Length An 8-bit, unsigned integer indicating the length of the option in octets, excluding the Type and Length fields. Reserved This field is unused in this specification. The value MUST be set to zero (0) by the sender and MUST be ignored by the receiver. LMA User-Plane Address Contains the 32-bit IPv4 address or the 128-bit IPv6 address of the LMA user plane. When the LMA User-Plane Address mobility option is included in a PBU message, this field can be a zero- length field, or it can have a value of ALL_ZERO, with all bits in the 32-bit IPv4 address or the 128-bit IPv6 address set to zero. When including the LMA User-Plane Address mobility option in the PBU, the MAG must apply the following rules: o When using IPv4 transport for the user plane, the IP address field in the option MUST be either a zero-length field or a 4-octet field with ALL_ZERO value. o When using IPv6 transport for the user plane, the IP address field in the option MUST be either a zero-length field or a 16-octet field with ALL_ZERO value. When the LMA includes the LMA User-Plane Address mobility option in the PBA, the IP address field in the option MUST be set to the LMA's IPv4 or IPv6 address carrying user-plane traffic. o When using IPv4 transport for the user plane, the IP address field in the option is the IPv4 address carrying user-plane traffic. o When using IPv6 transport for the user plane, the IP address field in the option is the IPv6 address carrying user-plane traffic. The encapsulation mode that will be chosen for the user plane between the MAG and the LMA has to based on the considerations specified in [RFC5213] and [RFC5844].
Section 4. The Type value 59 for this mobility option has been allocated by IANA in the "Mobility Options" registry at <http://www.iana.org/assignments/mobility-parameters>. RFC5213] requires the signaling messages between the MAG and the LMA to be protected using end-to-end security association(s) offering integrity and data origin authentication. The Proxy Mobile IPv6 specification also requires IPsec [RFC4301] to be a mandatory-to-implement security mechanism. This document specifies an approach where the control-plane and user- plane functions of the MAG and LMA are separated and hosted on different IP nodes. In such deployment models, the nodes hosting those respective control-plane functions still have to meet the [RFC5213] security requirement listed above; specifically, the Proxy Mobile IPv6 signaling messages exchanged between these entities MUST be protected using end-to-end security association(s) offering integrity and data origin authentication. Furthermore, IPsec is a mandatory-to-implement security mechanism for the nodes hosting the control-plane function of the MAG and LMA. Additional documents may specify alternative security mechanisms for securing Proxy Mobile IPv6 signaling messages. The mobility entities in a Proxy Mobile IPv6 domain can enable a specific security mechanism based on either (1) static configuration or (2) dynamic negotiation (using any standard security negotiation protocols). As per the Proxy Mobile IPv6 specification, the use of IPsec for protecting the mobile node's user-plane traffic is optional. This specification keeps the same requirement and therefore requires the nodes hosting the user-plane functions of the MAG and the LMA to have IPsec as a mandatory-to-implement security mechanism but make the use of IPsec optional for user-plane traffic protection. The LMA User-Plane Address mobility option defined in this specification is for use in PBU and PBA messages. This option is carried like any other mobility header option as specified in [RFC5213]. Therefore, it inherits security guidelines from [RFC5213].
The IP address of the LMA user plane (the LMA-UPA), provided within the LMA User-Plane Address mobility option, MUST be a valid address under the administrative control associated with the LMA functional block. If the LMA user-plane and the LMA control-plane functions are hosted in different entities, any control messages between these two entities containing the LMA User-Plane Address mobility option MUST be protected using end-to-end security association(s) offering integrity and data origin authentication. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008, <http://www.rfc-editor.org/info/rfc5213>. [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010, <http://www.rfc-editor.org/info/rfc5844>. [MOBILE-SEPARATION] Wakikawa, R., Matsushima, S., Patil, B., Chen, B., Joachimpillai, D., and H. Deng, "Requirements and use cases for separating control and user planes in mobile network architectures", Work in Progress, draft-wakikawa-req-mobile-cp-separation-00, November 2013. [OpenFlow-Spec-v1.4.0] Open Networking Foundation, "OpenFlow Switch Specification, Version 1.4.0", October 2013. [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994, <http://www.rfc-editor.org/info/rfc1701>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998, <http://www.rfc-editor.org/info/rfc2473>. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005, <http://www.rfc-editor.org/info/rfc4213>. [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010, <http://www.rfc-editor.org/info/rfc5810>. [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011, <http://www.rfc-editor.org/info/rfc6275>. [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012, <http://www.rfc-editor.org/info/rfc6459>. [RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui, "Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6", RFC 6463, February 2012, <http://www.rfc-editor.org/info/rfc6463>. [STATELESS-UPLANE] Matsushima, S. and R. Wakikawa, "Stateless user-plane architecture for virtualized EPC (vEPC)", Work in Progress, draft-matsushima-stateless-uplane-vepc-03, July 2014.